{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-6.17.0-19-generic", "linux-image-6.17.0-19-generic", "linux-modules-6.17.0-19-generic", "linux-riscv-6.17-headers-6.17.0-19", "linux-riscv-6.17-tools-6.17.0-19", "linux-tools-6.17.0-19-generic" ], "removed": [ "linux-headers-6.17.0-14-generic", "linux-image-6.17.0-14-generic", "linux-modules-6.17.0-14-generic", "linux-riscv-6.17-headers-6.17.0-14", "linux-riscv-6.17-tools-6.17.0-14", "linux-tools-6.17.0-14-generic" ], "diff": [ "bsdextrautils", "bsdutils", "coreutils", "curl", "eject", "fdisk", "libblkid1:riscv64", "libcurl3t64-gnutls:riscv64", "libcurl4t64:riscv64", "libfdisk1:riscv64", "libfreetype6:riscv64", "libmount1:riscv64", "libnftables1:riscv64", "libnss3:riscv64", "libpython3.12-minimal:riscv64", "libpython3.12-stdlib:riscv64", "libpython3.12t64:riscv64", "libsmartcols1:riscv64", "libssh-4:riscv64", "libuuid1:riscv64", "linux-base", "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-libc-dev:riscv64", "linux-tools-common", "linux-virtual", "mount", "nftables", "openssh-client", "openssh-server", "openssh-sftp-server", "python3-cryptography", "python3.12", "python3.12-minimal", "snapd", "sosreport", "sudo", "util-linux", "uuid-runtime", "vim", "vim-common", "vim-runtime", "vim-tiny", "xxd" ] } }, "diff": { "deb": [ { "name": "bsdextrautils", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "bsdutils", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "1:2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "1:2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "coreutils", "from_version": { "source_package_name": "coreutils", "source_package_version": "9.4-3ubuntu6.1", "version": "9.4-3ubuntu6.1" }, "to_version": { "source_package_name": "coreutils", "source_package_version": "9.4-3ubuntu6.2", "version": "9.4-3ubuntu6.2" }, "cves": [], "launchpad_bugs_fixed": [ 2137373 ], "changes": [ { "cves": [], "log": [ "", " * Fix slow performance of 'du' on large directories (>= 10K files)", " on Lustre filesystems by skipping inode sorting. The default", " behaviour of sorting dirents by inode numbers negatively impacts", " performance on Lustre because it interferes with Lustre's ability", " to prefetch file metadata via statahead. (LP: #2137373)", " - d/p/lp2137373-skip-dirent-inode-sorting-for-lustre.patch", "" ], "package": "coreutils", "version": "9.4-3ubuntu6.2", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2137373 ], "author": "Munir Siddiqui ", "date": "Fri, 23 Jan 2026 18:30:04 +0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.7", "version": "8.5.0-2ubuntu10.7" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.8", "version": "8.5.0-2ubuntu10.8" }, "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2025-0167", "url": "https://ubuntu.com/security/CVE-2025-0167", "cve_description": "When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance.", "cve_priority": "low", "cve_public_date": "2025-02-05 10:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2025-0167", "url": "https://ubuntu.com/security/CVE-2025-0167", "cve_description": "When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance.", "cve_priority": "low", "cve_public_date": "2025-02-05 10:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: bad reuse of HTTP Negotiate connection", " - debian/patches/CVE-2026-1965-1.patch: fix reuse of connections using", " HTTP Negotiate in lib/url.c.", " - debian/patches/CVE-2026-1965-2.patch: fix copy and paste", " url_match_auth_nego mistake in lib/url.c.", " - CVE-2026-1965", " * SECURITY UPDATE: token leak with redirect and netrc", " - debian/patches/CVE-2026-3783.patch: only send bearer if auth is", " allowed in lib/http.c, tests/data/Makefile.inc, tests/data/test2006.", " - CVE-2026-3783", " * SECURITY UPDATE: wrong proxy connection reuse with credentials", " - debian/patches/CVE-2026-3784.patch: add additional tests in", " lib/url.c.", " - CVE-2026-3784", " * SECURITY UPDATE: netrc and default credential leak", " - debian/patches/CVE-2025-0167.patch: 'default' with no credentials is", " not a match in lib/netrc.c, tests/data/Makefile.inc,", " tests/data/test486.", " - CVE-2025-0167", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 10 Mar 2026 10:42:35 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "eject", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "fdisk", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libblkid1:riscv64", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl3t64-gnutls:riscv64", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.7", "version": "8.5.0-2ubuntu10.7" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.8", "version": "8.5.0-2ubuntu10.8" }, "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2025-0167", "url": "https://ubuntu.com/security/CVE-2025-0167", "cve_description": "When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance.", "cve_priority": "low", "cve_public_date": "2025-02-05 10:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2025-0167", "url": "https://ubuntu.com/security/CVE-2025-0167", "cve_description": "When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance.", "cve_priority": "low", "cve_public_date": "2025-02-05 10:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: bad reuse of HTTP Negotiate connection", " - debian/patches/CVE-2026-1965-1.patch: fix reuse of connections using", " HTTP Negotiate in lib/url.c.", " - debian/patches/CVE-2026-1965-2.patch: fix copy and paste", " url_match_auth_nego mistake in lib/url.c.", " - CVE-2026-1965", " * SECURITY UPDATE: token leak with redirect and netrc", " - debian/patches/CVE-2026-3783.patch: only send bearer if auth is", " allowed in lib/http.c, tests/data/Makefile.inc, tests/data/test2006.", " - CVE-2026-3783", " * SECURITY UPDATE: wrong proxy connection reuse with credentials", " - debian/patches/CVE-2026-3784.patch: add additional tests in", " lib/url.c.", " - CVE-2026-3784", " * SECURITY UPDATE: netrc and default credential leak", " - debian/patches/CVE-2025-0167.patch: 'default' with no credentials is", " not a match in lib/netrc.c, tests/data/Makefile.inc,", " tests/data/test486.", " - CVE-2025-0167", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 10 Mar 2026 10:42:35 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl4t64:riscv64", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.7", "version": "8.5.0-2ubuntu10.7" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.8", "version": "8.5.0-2ubuntu10.8" }, "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2025-0167", "url": "https://ubuntu.com/security/CVE-2025-0167", "cve_description": "When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance.", "cve_priority": "low", "cve_public_date": "2025-02-05 10:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-1965", "url": "https://ubuntu.com/security/CVE-2026-1965", "cve_description": "libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:15:00 UTC" }, { "cve": "CVE-2026-3783", "url": "https://ubuntu.com/security/CVE-2026-3783", "cve_description": "When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.", "cve_priority": "medium", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2026-3784", "url": "https://ubuntu.com/security/CVE-2026-3784", "cve_description": "curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.", "cve_priority": "low", "cve_public_date": "2026-03-11 11:16:00 UTC" }, { "cve": "CVE-2025-0167", "url": "https://ubuntu.com/security/CVE-2025-0167", "cve_description": "When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance.", "cve_priority": "low", "cve_public_date": "2025-02-05 10:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: bad reuse of HTTP Negotiate connection", " - debian/patches/CVE-2026-1965-1.patch: fix reuse of connections using", " HTTP Negotiate in lib/url.c.", " - debian/patches/CVE-2026-1965-2.patch: fix copy and paste", " url_match_auth_nego mistake in lib/url.c.", " - CVE-2026-1965", " * SECURITY UPDATE: token leak with redirect and netrc", " - debian/patches/CVE-2026-3783.patch: only send bearer if auth is", " allowed in lib/http.c, tests/data/Makefile.inc, tests/data/test2006.", " - CVE-2026-3783", " * SECURITY UPDATE: wrong proxy connection reuse with credentials", " - debian/patches/CVE-2026-3784.patch: add additional tests in", " lib/url.c.", " - CVE-2026-3784", " * SECURITY UPDATE: netrc and default credential leak", " - debian/patches/CVE-2025-0167.patch: 'default' with no credentials is", " not a match in lib/netrc.c, tests/data/Makefile.inc,", " tests/data/test486.", " - CVE-2025-0167", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 10 Mar 2026 10:42:35 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libfdisk1:riscv64", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libfreetype6:riscv64", "from_version": { "source_package_name": "freetype", "source_package_version": "2.13.2+dfsg-1build3", "version": "2.13.2+dfsg-1build3" }, "to_version": { "source_package_name": "freetype", "source_package_version": "2.13.2+dfsg-1ubuntu0.1", "version": "2.13.2+dfsg-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-23865", "url": "https://ubuntu.com/security/CVE-2026-23865", "cve_description": "An integer overflow in the tt_var_load_item_variation_store function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.", "cve_priority": "medium", "cve_public_date": "2026-03-02 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-23865", "url": "https://ubuntu.com/security/CVE-2026-23865", "cve_description": "An integer overflow in the tt_var_load_item_variation_store function of the Freetype library in versions 2.13.2 and 2.13.3 may allow for an out of bounds read operation when parsing HVAR/VVAR/MVAR tables in OpenType variable fonts. This issue is fixed in version 2.14.2.", "cve_priority": "medium", "cve_public_date": "2026-03-02 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Integer Overflow", " - debian/patches/CVE-2026-23865.patch: Check for overflow in array", " size computation", " - CVE-2026-23865", "" ], "package": "freetype", "version": "2.13.2+dfsg-1ubuntu0.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 17:40:24 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "libmount1:riscv64", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libnftables1:riscv64", "from_version": { "source_package_name": "nftables", "source_package_version": "1.0.9-1build1", "version": "1.0.9-1build1" }, "to_version": { "source_package_name": "nftables", "source_package_version": "1.0.9-1ubuntu0.1", "version": "1.0.9-1ubuntu0.1" }, "cves": [], "launchpad_bugs_fixed": [ 2142552 ], "changes": [ { "cves": [], "log": [ "", " * netlink: fix crash when ops doesn't support udata (LP: #2142552)", "" ], "package": "nftables", "version": "1.0.9-1ubuntu0.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2142552 ], "author": "Dimitri John Ledkov ", "date": "Tue, 24 Feb 2026 08:16:27 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libnss3:riscv64", "from_version": { "source_package_name": "nss", "source_package_version": "2:3.98-1build1", "version": "2:3.98-1build1" }, "to_version": { "source_package_name": "nss", "source_package_version": "2:3.98-1ubuntu0.1", "version": "2:3.98-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2026-2781", "url": "https://ubuntu.com/security/CVE-2026-2781", "cve_description": "Integer overflow in the Libraries component in NSS. This vulnerability affects Firefox < 148, Firefox ESR < 140.8, Thunderbird < 148, and Thunderbird < 140.8.", "cve_priority": "medium", "cve_public_date": "2026-02-24 14:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-2781", "url": "https://ubuntu.com/security/CVE-2026-2781", "cve_description": "Integer overflow in the Libraries component in NSS. This vulnerability affects Firefox < 148, Firefox ESR < 140.8, Thunderbird < 148, and Thunderbird < 140.8.", "cve_priority": "medium", "cve_public_date": "2026-02-24 14:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: integer overflow in platform-independent ghash", " - debian/patches/CVE-2026-2781.patch: properly cast len in", " nss/lib/freebl/gcm.c.", " - CVE-2026-2781", "" ], "package": "nss", "version": "2:3.98-1ubuntu0.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 26 Feb 2026 13:27:34 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.12-minimal:riscv64", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.12", "version": "3.12.3-1ubuntu0.12" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.12", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:45:18 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.12-stdlib:riscv64", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.12", "version": "3.12.3-1ubuntu0.12" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.12", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:45:18 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpython3.12t64:riscv64", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.12", "version": "3.12.3-1ubuntu0.12" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.12", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:45:18 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsmartcols1:riscv64", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libssh-4:riscv64", "from_version": { "source_package_name": "libssh", "source_package_version": "0.10.6-2ubuntu0.3", "version": "0.10.6-2ubuntu0.3" }, "to_version": { "source_package_name": "libssh", "source_package_version": "0.10.6-2ubuntu0.4", "version": "0.10.6-2ubuntu0.4" }, "cves": [ { "cve": "CVE-2026-3731", "url": "https://ubuntu.com/security/CVE-2026-3731", "cve_description": "A weakness has been identified in libssh up to 0.11.3. The impacted element is the function sftp_extensions_get_name/sftp_extensions_get_data of the file src/sftp.c of the component SFTP Extension Name Handler. Executing a manipulation of the argument idx can lead to out-of-bounds read. The attack may be performed from remote. Upgrading to version 0.11.4 and 0.12.0 is sufficient to resolve this issue. This patch is called 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60. You should upgrade the affected component.", "cve_priority": "medium", "cve_public_date": "2026-03-08 11:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3731", "url": "https://ubuntu.com/security/CVE-2026-3731", "cve_description": "A weakness has been identified in libssh up to 0.11.3. The impacted element is the function sftp_extensions_get_name/sftp_extensions_get_data of the file src/sftp.c of the component SFTP Extension Name Handler. Executing a manipulation of the argument idx can lead to out-of-bounds read. The attack may be performed from remote. Upgrading to version 0.11.4 and 0.12.0 is sufficient to resolve this issue. This patch is called 855a0853ad3abd4a6cd85ce06fce6d8d4c7a0b60. You should upgrade the affected component.", "cve_priority": "medium", "cve_public_date": "2026-03-08 11:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: out-of-bound read", " - debian/patches/CVE-2026-3731.patch: correct bounds checks when querying", " for an SFTP extension name or data in src/sftp.c.", " - CVE-2026-3731", "" ], "package": "libssh", "version": "0.10.6-2ubuntu0.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Ian Constantin ", "date": "Wed, 11 Mar 2026 12:24:58 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "libuuid1:riscv64", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-base", "from_version": { "source_package_name": "linux-base", "source_package_version": "4.5ubuntu9+24.04.1", "version": "4.5ubuntu9+24.04.1" }, "to_version": { "source_package_name": "linux-base", "source_package_version": "4.5ubuntu9+24.04.2", "version": "4.5ubuntu9+24.04.2" }, "cves": [], "launchpad_bugs_fixed": [ 2141393 ], "changes": [ { "cves": [], "log": [ "", " * Add missing Apport links for HWE (and other new) kernel packages", " (LP: #2141393).", "" ], "package": "linux-base", "version": "4.5ubuntu9+24.04.2", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141393 ], "author": "Juerg Haefliger ", "date": "Mon, 23 Feb 2026 10:52:34 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "to_version": { "source_package_name": "linux-meta-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1975592 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.17.0-19.19.1~24.04.1", "" ], "package": "linux-meta-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:38:07 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.17.0-16.16.1~24.04.1", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "", " * Enable Nezha board (LP: #1975592)", " - [Packaging] Add allwinner transitionals", "" ], "package": "linux-meta-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013, 1975592 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:56:56 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "to_version": { "source_package_name": "linux-meta-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1975592 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.17.0-19.19.1~24.04.1", "" ], "package": "linux-meta-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:38:07 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.17.0-16.16.1~24.04.1", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "", " * Enable Nezha board (LP: #1975592)", " - [Packaging] Add allwinner transitionals", "" ], "package": "linux-meta-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013, 1975592 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:56:56 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "to_version": { "source_package_name": "linux-meta-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1975592 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.17.0-19.19.1~24.04.1", "" ], "package": "linux-meta-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:38:07 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.17.0-16.16.1~24.04.1", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "", " * Enable Nezha board (LP: #1975592)", " - [Packaging] Add allwinner transitionals", "" ], "package": "linux-meta-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013, 1975592 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:56:56 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-libc-dev:riscv64", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-101.101", "version": "6.8.0-101.101" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-106.106", "version": "6.8.0-106.106" }, "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68198", "url": "https://ubuntu.com/security/CVE-2025-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crash: fix crashkernel resource shrink When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues: 1. Invalid crashkernel resource objects 2. Kernel crash if crashkernel shrinking is done twice For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as: cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel Instead, it should show 50MB: af000000-b21fffff : Crash kernel Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86): BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated. Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-38627", "url": "https://ubuntu.com/security/CVE-2025-38627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic The decompress_io_ctx may be released asynchronously after I/O completion. If this file is deleted immediately after read, and the kworker of processing post_read_wq has not been executed yet due to high workloads, It is possible that the inode(f2fs_inode_info) is evicted and freed before it is used f2fs_free_dic. The UAF case as below: Thread A Thread B - f2fs_decompress_end_io - f2fs_put_dic - queue_work add free_dic work to post_read_wq - do_unlink - iput - evict - call_rcu This file is deleted after read. Thread C kworker to process post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inode is freed by rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem read (dic->inode)->i_compress_algorithm This patch store compress_algorithm and sbi in dic to avoid inode UAF. In addition, the previous solution is deprecated in [1] may cause system hang. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68204", "url": "https://ubuntu.com/security/CVE-2025-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: arm: scmi: Fix genpd leak on provider registration failure If of_genpd_add_provider_onecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpd_debug_add(). Add proper error handling to unwind the initialized domains before returning from probe to ensure all resources are correctly released on failure. Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39981", "url": "https://ubuntu.com/security/CVE-2025-39981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible UAFs This attemps to fix possible UAFs caused by struct mgmt_pending being freed while still being processed like in the following trace, in order to fix mgmt_pending_valid is introduce and use to check if the mgmt_pending hasn't been removed from the pending list, on the complete callbacks it is used to check and in addtion remove the cmd from the list while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd is left on the list it can still be accessed and freed. BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55 CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 Allocated by task 12210: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x258/0x330 net/socket.c:1133 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 12221: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-22121", "url": "https://ubuntu.com/security/CVE-2025-22121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-23129", "url": "https://ubuntu.com/security/CVE-2025-23129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath11k_pci_alloc_msi(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This results in the below warning: WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c Call trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc The warning is due to not clearing the affinity hint before freeing the IRQs. So to fix this issue, clear the IRQ affinity hint before calling ath11k_pcic_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-40287", "url": "https://ubuntu.com/security/CVE-2025-40287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix improper check of dentry.stream.valid_size We found an infinite loop bug in the exFAT file system that can lead to a Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is malformed, the following system calls — SYS_openat, SYS_ftruncate, and SYS_pwrite64 — can cause the kernel to hang. Root cause analysis shows that the size validation code in exfat_find() does not check whether dentry.stream.valid_size is negative. As a result, the system calls mentioned above can succeed and eventually trigger the DoS issue. This patch adds a check for negative dentry.stream.valid_size to prevent this vulnerability.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40289", "url": "https://ubuntu.com/security/CVE-2025-40289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM Otherwise accessing them can cause a crash.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68201", "url": "https://ubuntu.com/security/CVE-2025-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: remove two invalid BUG_ON()s Those can be triggered trivially by userspace.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68180", "url": "https://ubuntu.com/security/CVE-2025-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref in debugfs odm_combine_segments When a connector is connected but inactive (e.g., disabled by desktop environments), pipe_ctx->stream_res.tg will be destroyed. Then, reading odm_combine_segments causes kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Fix this by checking pipe_ctx-> ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68322", "url": "https://ubuntu.com/security/CVE-2025-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Avoid crash due to unaligned access in unwinder Guenter Roeck reported this kernel crash on his emulated B160L machine: Starting network: udhcpc: started, v1.36.1 Backtrace: [<104320d4>] unwind_once+0x1c/0x5c [<10434a00>] walk_stackframe.isra.0+0x74/0xb8 [<10434a6c>] arch_stack_walk+0x28/0x38 [<104e5efc>] stack_trace_save+0x48/0x5c [<105d1bdc>] set_track_prepare+0x44/0x6c [<105d9c80>] ___slab_alloc+0xfc4/0x1024 [<105d9d38>] __slab_alloc.isra.0+0x58/0x90 [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0 [<105b8e54>] __anon_vma_prepare+0x60/0x280 [<105a823c>] __vmf_anon_prepare+0x68/0x94 [<105a8b34>] do_wp_page+0x8cc/0xf10 [<105aad88>] handle_mm_fault+0x6c0/0xf08 [<10425568>] do_page_fault+0x110/0x440 [<10427938>] handle_interruption+0x184/0x748 [<11178398>] schedule+0x4c/0x190 BUG: spinlock recursion on CPU#0, ifconfig/2420 lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0 While creating the stack trace, the unwinder uses the stack pointer to guess the previous frame to read the previous stack pointer from memory. The crash happens, because the unwinder tries to read from unaligned memory and as such triggers the unalignment trap handler which then leads to the spinlock recursion and finally to a deadlock. Fix it by checking the alignment before accessing the memory.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40305", "url": "https://ubuntu.com/security/CVE-2025-40305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq) if list_empty(&m->req_list). However, if the pipe is full, we need to read more data and this used to work prior to commit aaec5a95d59615 (\"pipe_read: don't wake up the writer if the pipe is still full\"). p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before the commit above) triggered the unnecessary wakeup. This wakeup calls p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux() will notice EPOLLIN and schedule_work(&m->rq). This no longer happens after the optimization above, change p9_fd_request() to use p9_poll_mux() instead of only checking for EPOLLOUT.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40307", "url": "https://ubuntu.com/security/CVE-2025-40307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: validate cluster allocation bits of the allocation bitmap syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68315", "url": "https://ubuntu.com/security/CVE-2025-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to detect potential corrupted nid in free_nid_list As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40339", "url": "https://ubuntu.com/security/CVE-2025-40339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix nullptr err of vm_handle_moved If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68311", "url": "https://ubuntu.com/security/CVE-2025-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: ip22zilog: Use platform device for probing After commit 84a9582fd203 (\"serial: core: Start managing serial controllers to enable runtime PM\") serial drivers need to provide a device in struct uart_port.dev otherwise an oops happens. To fix this issue for ip22zilog driver switch driver to a platform driver and setup the serial device in sgi-ip22 code.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68313", "url": "https://ubuntu.com/security/CVE-2025-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Add RDSEED fix for Zen5 There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 \"at a rate inconsistent with randomness while incorrectly signaling success (CF=1)\". Search the web for AMD-SB-7055 for more detail. Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40360", "url": "https://ubuntu.com/security/CVE-2025-40360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Do not dereference NULL pointer in plane reset The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68734", "url": "https://ubuntu.com/security/CVE-2025-68734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe() In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style. Compile tested only. Issue found using a prototype static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-40272", "url": "https://ubuntu.com/security/CVE-2025-40272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix use-after-free race in fault handler When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40077", "url": "https://ubuntu.com/security/CVE-2025-40077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid overflow while left shift operation Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-68245", "url": "https://ubuntu.com/security/CVE-2025-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit efa95b01da18 (\"netpoll: fix use after free\") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 (\"netpoll: fix use after free\") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40293", "url": "https://ubuntu.com/security/CVE-2025-40293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Don't overflow during division for dirty tracking If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow to 0 and this triggers divide by 0. In this case the index should just be 0, so reorganize things to divide by shift and avoid hitting any overflows.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40303", "url": "https://ubuntu.com/security/CVE-2025-40303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: ensure no dirty metadata is written back for an fs with errors [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68184", "url": "https://ubuntu.com/security/CVE-2025-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Disable AFBC support on Mediatek DRM driver Commit c410fa9b07c3 (\"drm/mediatek: Add AFBC support to Mediatek DRM driver\") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier. However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0. Kernel trace reports vblank timeouts constantly, and the render is garbled: ``` [CRTC:62:crtc-0] vblank wait timed out WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c [...] Hardware name: MediaTek Genio-700 EVK (DT) Workqueue: events_unbound commit_work pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c sp : ffff80008337bca0 x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000 x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70 x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ``` Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40268", "url": "https://ubuntu.com/security/CVE-2025-40268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: client: fix memory leak in smb3_fs_context_parse_param The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation. To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing. syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444 BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40269", "url": "https://ubuntu.com/security/CVE-2025-40269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential overflow of PCM transfer buffer The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0].", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40271", "url": "https://ubuntu.com/security/CVE-2025-40271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix uaf in proc_readdir_de() Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \\ NULL pde(tun2)", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68241", "url": "https://ubuntu.com/security/CVE-2025-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random. The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked. CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak] This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = N Ido Schimmel provided the simple test validation method [1]. The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed. [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \\ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \\ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \\ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-68246", "url": "https://ubuntu.com/security/CVE-2025-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: close accepted socket when per-IP limit rejects connection When the per-IP connection limit is exceeded in ksmbd_kthread_fn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS. Release client_sk before continuing. This bug was found with ZeroPath.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40273", "url": "https://ubuntu.com/security/CVE-2025-40273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: free copynotify stateid in nfs4_free_ol_stateid() Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period. However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd] This patch, instead, frees the associated copynotify stateid here. If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later. [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68208", "url": "https://ubuntu.com/security/CVE-2025-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: account for current allocated stack depth in widen_imprecise_scalars() The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st); Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loop Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68200", "url": "https://ubuntu.com/security/CVE-2025-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add bpf_prog_run_data_pointers() syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 (\"net/sched: Extend qdisc control block with tc control block\"), which added a wrong interaction with db58ba459202 (\"bpf: wire in data and data_end for cls_act_bpf\"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40275", "url": "https://ubuntu.com/security/CVE-2025-40275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd In snd_usb_create_streams(), for UAC version 3 devices, the Interface Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this call fails, a fallback routine attempts to obtain the IAD from the next interface and sets a BADD profile. However, snd_usb_mixer_controls_badd() assumes that the IAD retrieved from usb_ifnum_to_if() is always valid, without performing a NULL check. This can lead to a NULL pointer dereference when usb_ifnum_to_if() fails to find the interface descriptor. This patch adds a NULL pointer check after calling usb_ifnum_to_if() in snd_usb_mixer_controls_badd() to prevent the dereference. This issue was discovered by syzkaller, which triggered the bug by sending a crafted USB device descriptor.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40277", "url": "https://ubuntu.com/security/CVE-2025-40277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40278", "url": "https://ubuntu.com/security/CVE-2025-40278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak Fix a KMSAN kernel-infoleak detected by the syzbot . [net?] KMSAN: kernel-infoleak in __skb_datagram_iter In tcf_ife_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. This change silences the KMSAN report and prevents potential information leaks from the kernel memory. This fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures no infoleak.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40279", "url": "https://ubuntu.com/security/CVE-2025-40279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_connmark: initialize struct tc_ife to fix kernel leak In tcf_connmark_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40280", "url": "https://ubuntu.com/security/CVE-2025-40280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_mon_reinit_self(). syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0] The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL. tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work(). Let's hold RTNL in tipc_net_finalize_work(). [0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989 CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40281", "url": "https://ubuntu.com/security/CVE-2025-40281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto syzbot reported a possible shift-out-of-bounds [1] Blamed commit added rto_alpha_max and rto_beta_max set to 1000. It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta. In order to prevent user regression, perform the test at run time. Also add READ_ONCE() annotations as sysctl values can change under us. [1] UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40282", "url": "https://ubuntu.com/security/CVE-2025-40282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: 6lowpan: reset link-local header on ipv6 recv path Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW Add missing skb_reset_mac_header() for uncompressed ipv6 RX path. For the compressed one, it is done in lowpan_header_decompress(). Log: (BlueZ 6lowpan-tester Client Recv Raw - Success) ------ kernel BUG at net/core/skbuff.c:212! Call Trace: ... packet_rcv (net/packet/af_packet.c:2152) ... __local_bh_enable_ip (kernel/softirq.c:407) netif_rx (net/core/dev.c:5648) chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359) ------", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40283", "url": "https://ubuntu.com/security/CVE-2025-40283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF There is a KASAN: slab-use-after-free read in btusb_disconnect(). Calling \"usb_driver_release_interface(&btusb_driver, data->intf)\" will free the btusb data associated with the interface. The same data is then used later in the function, hence the UAF. Fix by moving the accesses to btusb data to before the data is free'd.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40284", "url": "https://ubuntu.com/security/CVE-2025-40284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in \"Mesh - Send cancel - 1\" test). Log: ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40285", "url": "https://ubuntu.com/security/CVE-2025-40285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix possible refcount leak in smb2_sess_setup() Reference count of ksmbd_session will leak when session need reconnect. Fix this by adding the missing ksmbd_user_session_put().", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40286", "url": "https://ubuntu.com/security/CVE-2025-40286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix possible memory leak in smb2_read() Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree().", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40288", "url": "https://ubuntu.com/security/CVE-2025-40288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices Previously, APU platforms (and other scenarios with uninitialized VRAM managers) triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL, but that `man->bdev` (the backing device pointer within the manager) remains uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to a kernel OOPS. 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference. 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL. 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report). This approach is more robust than APU-specific checks because it: - Works for all scenarios where the VRAM manager is uninitialized (not just APUs), - Aligns with TTM's design by using its native helper function, - Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check). v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68244", "url": "https://ubuntu.com/security/CVE-2025-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x16 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40292", "url": "https://ubuntu.com/security/CVE-2025-40292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix received length check in big packets Since commit 4959aebba8c0 (\"virtio-net: use mtu size as buffer length for big packets\"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40328", "url": "https://ubuntu.com/security/CVE-2025-40328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_close_cached_fid() find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free. Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40294", "url": "https://ubuntu.com/security/CVE-2025-40294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern() In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied. Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40329", "url": "https://ubuntu.com/security/CVE-2025-40329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()). CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0. Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock This will deadlock if f1 and f2 share the same spinlock. To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work(). [phasta: commit message nits]", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68320", "url": "https://ubuntu.com/security/CVE-2025-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix sleeping in atomic context The following warning was seen when we try to connect using ssh to the device. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear preempt_count: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE Tainted: [W]=WARN Hardware name: Generic DT based system Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8 It seems that we are using a mutex in a atomic context which is wrong. Change the mutex with a spinlock.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68192", "url": "https://ubuntu.com/security/CVE-2025-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks. Initialize the MAC header to prevent such crashes. This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface. Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40331", "url": "https://ubuntu.com/security/CVE-2025-40331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: Prevent TOCTOU out-of-bounds write For the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use).", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40301", "url": "https://ubuntu.com/security/CVE-2025-40301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: validate skb length for unknown CC opcode In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory. The fix is to check skb->len before using skb->data.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40358", "url": "https://ubuntu.com/security/CVE-2025-40358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: stacktrace: Disable KASAN checks for non-current tasks Unwinding the stack of a task other than current, KASAN would report \"BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460\" There is a same issue on x86 and has been resolved by the commit 84936118bdf3 (\"x86/unwind: Disable KASAN checks for non-current tasks\") The solution could be applied to RISC-V too. This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23 [pjw@kernel.org: clean up checkpatch issues]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40304", "url": "https://ubuntu.com/security/CVE-2025-40304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches. Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68183", "url": "https://ubuntu.com/security/CVE-2025-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with \"ima_appraise=fix evm=fix ima_policy=appraise_tcb\" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = \"/usr/sbin/test_binary\"; const char* hex_string = \"030204d33204490066306402304\"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror(\"Error opening file\"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, \"%2hhx\", &ima_attr_value[j]); } if (fsetxattr(fd, \"security.ima\", ima_attr_value, length/2, 0) == -1) { perror(\"Error setting extended attribute\"); close(fd); return 1; } const char* selinux_value= \"system_u:object_r:bin_t:s0\"; if (fsetxattr(fd, \"security.selinux\", selinux_value, strlen(selinux_value), 0) == -1) { perror(\"Error setting extended attribute\"); close(fd); return 1; } close(fd); return 0; }", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68173", "url": "https://ubuntu.com/security/CVE-2025-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix softlockup in ftrace_module_enable A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc (\"ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels\") and commit 42ea22e754ba (\"ftrace: Add cond_resched() to ftrace_graph_set_hash()\"). Fix it the same way by adding cond_resched() in ftrace_module_enable.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40306", "url": "https://ubuntu.com/security/CVE-2025-40306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau forwarded me a message from Disclosure with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr \"security.capability\" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for \"security.capability\" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40308", "url": "https://ubuntu.com/security/CVE-2025-40308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bcsp: receive data only if registered Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40309", "url": "https://ubuntu.com/security/CVE-2025-40309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on sco_conn_free BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline] BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline] BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352 CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci13 hci_cmd_sync_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40310", "url": "https://ubuntu.com/security/CVE-2025-40310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw There is race in amdgpu_amdkfd_device_fini_sw and interrupt. if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated. kernel panic log: BUG: kernel NULL pointer dereference, address: 0000000000000098 amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP PGD d78c68067 P4D d78c68067 kfd kfd: amdgpu: Allocated 3969056 bytes on gart PUD 1465b8067 PMD @ Oops: @002 [#1] SMP NOPTI kfd kfd: amdgpu: Total number of KFD nodes to be created: 4 CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40 Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc 89 c6 e8 07 38 5d RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018 0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098 ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020 0000000000000000 R11: 0000000000000000 R12: 0900000000000002 ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00 CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033 CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400 PKRU: 55555554 Call Trace: kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu] ? amdgpu_fence_process+0xa4/0x150 [amdgpu] kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace amdgpu_irq_dispatch+0x165/0x210 [amdgpu] amdgpu_ih_process+0x80/0x100 [amdgpu] amdgpu: Virtual CRAT table created for GPU amdgpu_irq_handler+0x1f/@x60 [amdgpu] __handle_irq_event_percpu+0x3d/0x170 amdgpu: Topology: Add dGPU node [0x74a2:0x1002] handle_irq_event+0x5a/@xcO handle_edge_irq+0x93/0x240 kfd kfd: amdgpu: KFD node 1 partition @ size 49148M asm_call_irq_on_stack+0xf/@x20 common_interrupt+0xb3/0x130 asm_common_interrupt+0x1le/0x40 5.10.134-010.a1i5000.a18.x86_64 #1", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40311", "url": "https://ubuntu.com/security/CVE-2025-40311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: support mapping cb with vmalloc-backed coherent memory When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction. Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68185", "url": "https://ubuntu.com/security/CVE-2025-68185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68176", "url": "https://ubuntu.com/security/CVE-2025-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: cadence: Check for the existence of cdns_pcie::ops before using it cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. [mani: reworded subject and description]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68168", "url": "https://ubuntu.com/security/CVE-2025-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix uninitialized waitqueue in transaction manager The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems. When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0. This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEnd Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40312", "url": "https://ubuntu.com/security/CVE-2025-40312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Verify inode mode when loading from disk The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 (\"isofs: Verify inode mode when loading from disk\") does.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40333", "url": "https://ubuntu.com/security/CVE-2025-40333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix infinite loop in __insert_extent_tree() When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68321", "url": "https://ubuntu.com/security/CVE-2025-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: page_pool: always add GFP_NOWARN for ATOMIC allocations Driver authors often forget to add GFP_NOWARN for page allocation from the datapath. This is annoying to users as OOMs are a fact of life, and we pretty much expect network Rx to hit page allocation failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations by default.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68191", "url": "https://ubuntu.com/security/CVE-2025-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: use netdev_warn() instead of netdev_WARN() netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug. udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug. Replace netdev_WARN() with netdev_warn() accordingly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40313", "url": "https://ubuntu.com/security/CVE-2025-40313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: pretend $Extend records as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40314", "url": "https://ubuntu.com/security/CVE-2025-40314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free. Fix: By separating the usb_del_gadget_udc() operation into distinct \"del\" and \"put\" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget(). A patch similar to bb9c74a5bd14(\"usb: dwc3: gadget: Free gadget structure only after freeing endpoints\").", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40337", "url": "https://ubuntu.com/security/CVE-2025-40337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Correctly handle Rx checksum offload errors The stmmac_rx function would previously set skb->ip_summed to CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype. However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause corrupt packets to be passed up the network stack as valid. This patch corrects the logic by checking the `csum_none` status flag, which is set when the hardware reports a checksum error. If this flag is set, skb->ip_summed is now correctly set to CHECKSUM_NONE, ensuring the kernel's network stack will perform its own validation and properly handle the corrupt packet.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68194", "url": "https://ubuntu.com/security/CVE-2025-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imon: make send_packet() more robust syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1]. First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls). Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away. but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed. Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb). Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf (\"[media] imon: don't wedge hardware after early callbacks\"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a (\"[media] imon: don't parse scancodes until intf configured\") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task). Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40363", "url": "https://ubuntu.com/security/CVE-2025-40363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix field-spanning memcpy warning in AH output Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field \"&top_iph->saddr\" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439 The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68178", "url": "https://ubuntu.com/security/CVE-2025-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix possible deadlock while configuring policy Following deadlock can be triggered easily by lockdep: WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180 but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30 -> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock); Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context. The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40341", "url": "https://ubuntu.com/security/CVE-2025-40341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Don't leak robust_list pointer on exec race sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged. A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec(). For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process. This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk. Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40342", "url": "https://ubuntu.com/security/CVE-2025-40342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: use lock accessing port_state and rport state nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40343", "url": "https://ubuntu.com/security/CVE-2025-40343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid scheduling association deletion twice When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68177", "url": "https://ubuntu.com/security/CVE-2025-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq/longhaul: handle NULL policy in longhaul_exit longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic. This patch adds a check using unlikely() and returns early if the policy is NULL. Bugzilla: #219962", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40315", "url": "https://ubuntu.com/security/CVE-2025-40315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix epfile null pointer access after ep enable. A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable(). The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock. Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68310", "url": "https://ubuntu.com/security/CVE-2025-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do. During error recovery testing a pair of tasks was reported to be hung: mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core] No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too: - task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock() - task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock. A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/ reporter fw_fatal while PCI error recovery is executed on the same physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with \"kernel answers: Permission denied\" - and we get a kernel log message of: mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5 because the config read of VSC_SEMAPHORE is rejected by the underlying hardware. Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68179", "url": "https://ubuntu.com/security/CVE-2025-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible crashes. The problem is that kernel page tables are modified without flushing corresponding TLB entries. Even if it looks like the empty flush_tlb_all() implementation on s390 is the problem, it is actually a different problem: on s390 it is not allowed to replace an active/valid page table entry with another valid page table entry without the detour over an invalid entry. A direct replacement may lead to random crashes and/or data corruption. In order to invalidate an entry special instructions have to be used (e.g. ipte or idte). Alternatively there are also special instructions available which allow to replace a valid entry with a different valid entry (e.g. crdte or cspg). Given that the HVO code currently does not provide the hooks to allow for an implementation which is compliant with the s390 architecture requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is basically a revert of the original patch which enabled it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40317", "url": "https://ubuntu.com/security/CVE-2025-40317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: slimbus: fix bus_context pointer in regmap init calls Commit 4e65bda8273c (\"ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()\") revealed the problem in the slimbus regmap. That commit breaks audio playback, for instance, on sdm845 Thundercomm Dragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19c The __devm_regmap_init_slimbus() started to be used instead of __regmap_init_slimbus() after the commit mentioned above and turns out the incorrect bus_context pointer (3rd argument) was used in __devm_regmap_init_slimbus(). It should be just \"slimbus\" (which is equal to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or the first user of devm_regmap_init_slimbus() but we should fix it till the point where __devm_regmap_init_slimbus() was introduced therefore two \"Fixes\" tags. While at this, also correct the same argument in __regmap_init_slimbus().", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40318", "url": "https://ubuntu.com/security/CVE-2025-40318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and \"UAF\". Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68312", "url": "https://ubuntu.com/security/CVE-2025-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Prevents free active kevent The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the \"free active object (kevent)\" error reported here. 2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed. The solution to this problem is to cancel the kevent before executing free_netdev().", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68172", "url": "https://ubuntu.com/security/CVE-2025-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aspeed - fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the manual clock cleanup in both aspeed_acry_probe()'s error path and aspeed_acry_remove().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40319", "url": "https://ubuntu.com/security/CVE-2025-40319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Sync pending IRQ work before freeing ring buffer Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work complete before freeing the buffer.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68171", "url": "https://ubuntu.com/security/CVE-2025-68171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Ensure XFD state on signal delivery Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40320", "url": "https://ubuntu.com/security/CVE-2025-40320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential cfid UAF in smb2_query_info_compound When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free. Reinitialize cfid to NULL under the replay label. Example trace (trimmed): refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40321", "url": "https://ubuntu.com/security/CVE-2025-40321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the \"actframe\" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for \"send_af_done\" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. [Cc stable]", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40322", "url": "https://ubuntu.com/security/CVE-2025-40322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_putcs* bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40211", "url": "https://ubuntu.com/security/CVE-2025-40211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: video: Fix use-after-free in acpi_video_switch_brightness() The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed. [ rjw: Changelog edit ]", "cve_priority": "medium", "cve_public_date": "2025-11-21 11:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40324", "url": "https://ubuntu.com/security/CVE-2025-40324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix crash in nfsd4_read_release() When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-37860", "url": "https://ubuntu.com/security/CVE-2025-37860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: fix NULL dereferences in ef100_process_design_param() Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point. Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err.", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21833", "url": "https://ubuntu.com/security/CVE-2025-21833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE There is a WARN_ON_ONCE to catch an unlikely situation when domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless happens we must avoid using a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-22105", "url": "https://ubuntu.com/security/CVE-2025-22105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: check xdp prog when set bond mode Following operations can trigger a warning[1]: ip netns add ns1 ip netns exec ns1 ip link add bond0 type bond mode balance-rr ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp ip netns exec ns1 ip link set bond0 type bond mode broadcast ip netns del ns1 When delete the namespace, dev_xdp_uninstall() is called to remove xdp program on bond dev, and bond_xdp_set() will check the bond mode. If bond mode is changed after attaching xdp program, the warning may occur. Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode with xdp program attached is not good. Add check for xdp program when set bond mode. [1] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930 Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ... RSP: 0018:ffffc90000063d80 EFLAGS: 00000282 RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48 RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8 R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000 FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0 Call Trace: ? __warn+0x83/0x130 ? unregister_netdevice_many_notify+0x8d9/0x930 ? report_bug+0x18e/0x1a0 ? handle_bug+0x54/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? unregister_netdevice_many_notify+0x8d9/0x930 ? bond_net_exit_batch_rtnl+0x5c/0x90 cleanup_net+0x237/0x3d0 process_one_work+0x163/0x390 worker_thread+0x293/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0xec/0x1e0 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-23130", "url": "https://ubuntu.com/security/CVE-2025-23130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid panic once fallocation fails for pinfile syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation. In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg()", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-40353", "url": "https://ubuntu.com/security/CVE-2025-40353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: mte: Do not warn if the page is already tagged in copy_highpage() The arm64 copy_highpage() assumes that the destination page is newly allocated and not MTE-tagged (PG_mte_tagged unset) and warns accordingly. However, following commit 060913999d7a (\"mm: migrate: support poisoned recover from migrate folio\"), folio_mc_copy() is called before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the copy will be done again to the same destination page. Since copy_highpage() already set the PG_mte_tagged flag, this second copy will warn. Replace the WARN_ON_ONCE(page already tagged) in the arm64 copy_highpage() with a comment.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-39678", "url": "https://ubuntu.com/security/CVE-2025-39678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL If metric table address is not allocated, accessing metrics_bin will result in a NULL pointer dereference, so add a check.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-40235", "url": "https://ubuntu.com/security/CVE-2025-40235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots() If fs_info->super_copy or fs_info->super_for_commit allocated failed in btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info(). Otherwise btrfs_check_leaked_roots() would access NULL pointer because fs_info->allocated_roots had not been initialised. syzkaller reported the following information: ------------[ cut here ]------------ BUG: unable to handle page fault for address: fffffffffffffbb0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...) RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline] RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline] RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline] RIP: 0010:refcount_read include/linux/refcount.h:170 [inline] RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230 [...] Call Trace: btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280 btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029 btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097 vfs_get_tree+0x98/0x320 fs/super.c:1759 do_new_mount+0x357/0x660 fs/namespace.c:3899 path_mount+0x716/0x19c0 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount fs/namespace.c:4427 [inline] __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f032eaffa8d [...]", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40238", "url": "https://ubuntu.com/security/CVE-2025-40238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix IPsec cleanup over MPV device When we do mlx5e_detach_netdev() we eventually disable blocking events notifier, among those events are IPsec MPV events from IB to core. So before disabling those blocking events, make sure to also unregister the devcom device and mark all this device operations as complete, in order to prevent the other device from using invalid netdev during future devcom events which could cause the trace below. BUG: kernel NULL pointer dereference, address: 0000000000000010 PGD 146427067 P4D 146427067 PUD 146488067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40 RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206 RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00 RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000 R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600 R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80 FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core] mlx5_devcom_send_event+0x8c/0x170 [mlx5_core] blocking_event+0x17b/0x230 [mlx5_core] notifier_call_chain+0x35/0xa0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core] mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib] mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib] ? idr_alloc_cyclic+0x50/0xb0 ? __kmalloc_cache_noprof+0x167/0x340 ? __kmalloc_noprof+0x1a7/0x430 __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe9/0x310 [mlx5_ib] ? kernfs_add_one+0x107/0x150 ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] auxiliary_bus_probe+0x3e/0x90 really_probe+0xc5/0x3a0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x62d/0x830 __auxiliary_device_add+0x3b/0xa0 ? auxiliary_device_init+0x41/0x90 add_adev+0xd1/0x150 [mlx5_core] mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core] esw_mode_change+0x6c/0xc0 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x180/0x2b0 ? devlink_get_from_attrs_lock+0x170/0x170 ? devlink_nl_eswitch_get_doit+0x290/0x290 ? devlink_nl_pre_doit_port_optional+0x50/0x50 ? genl_family_rcv_msg_dumpit+0xf0/0xf0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1fc/0x2d0 netlink_sendmsg+0x1e4/0x410 __sock_sendmsg+0x38/0x60 ? sockfd_lookup_light+0x12/0x60 __sys_sendto+0x105/0x160 ? __sys_recvmsg+0x4e/0x90 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f27bc91b13a Code: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40242", "url": "https://ubuntu.com/security/CVE-2025-40242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix unlikely race in gdlm_put_lock In gdlm_put_lock(), there is a small window of time in which the DFL_UNMOUNT flag has been set but the lockspace hasn't been released, yet. In that window, dlm may still call gdlm_ast() and gdlm_bast(). To prevent it from dereferencing freed glock objects, only free the glock if the lockspace has actually been released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40083", "url": "https://ubuntu.com/security/CVE-2025-40083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: Fix null-deref in agg_dequeue To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c. To avoid code duplication, the following changes are made: 1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function. 2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it. 3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40084", "url": "https://ubuntu.com/security/CVE-2025-40084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: transport_ipc: validate payload size before reading handle handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing. This is a minimal fix to guard the initial handle read.", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40220", "url": "https://ubuntu.com/security/CVE-2025-40220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: \"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40237", "url": "https://ubuntu.com/security/CVE-2025-40237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/notify: call exportfs_encode_fid with s_umount Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr. This issue was found by syzkaller. Race Condition Diagram: Thread 1 Thread 2 -------- -------- generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb) Which then leads to: [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none) [ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240 IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path. Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock. This form of fix was suggested by Amir in [1]. [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68249", "url": "https://ubuntu.com/security/CVE-2025-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: hdm_probe: Fix calling put_device() before device initialization The early error path in hdm_probe() can jump to err_free_mdev before &mdev->dev has been initialized with device_initialize(). Calling put_device(&mdev->dev) there triggers a device core WARN and ends up invoking kref_put(&kobj->kref, kobject_release) on an uninitialized kobject. In this path the private struct was only kmalloc'ed and the intended release is effectively kfree(mdev) anyway, so free it directly instead of calling put_device() on an uninitialized device. This removes the WARNING and fixes the pre-initialization error path.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40223", "url": "https://ubuntu.com/security/CVE-2025-40223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: Fix use-after-free in hdm_disconnect hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing. The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts). Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface(). This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40106", "url": "https://ubuntu.com/security/CVE-2025-40106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: fix divide-by-zero in comedi_buf_munge() The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands.", "cve_priority": "medium", "cve_public_date": "2025-10-31 10:15:00 UTC" }, { "cve": "CVE-2025-40226", "url": "https://ubuntu.com/security/CVE-2025-40226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Account for failed debug initialization When the SCMI debug subsystem fails to initialize, the related debug root will be missing, and the underlying descriptor will be NULL. Handle this fault condition in the SCMI debug helpers that maintain metrics counters.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40231", "url": "https://ubuntu.com/security/CVE-2025-40231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix lock inversion in vsock_assign_transport() Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called. The issue was introduced by commit 687aa0c5581b (\"vsock: Fix transport_* TOCTOU\") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created. Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40233", "url": "https://ubuntu.com/security/CVE-2025-40233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: clear extent cache after moving/defragmenting extents The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters(). The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40346", "url": "https://ubuntu.com/security/CVE-2025-40346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arch_topology: Fix incorrect error check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: \"The error code within @ptr if it is an error pointer; 0 otherwise.\" This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40240", "url": "https://ubuntu.com/security/CVE-2025-40240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid NULL dereference when chunk data buffer is missing chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only. chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40350", "url": "https://ubuntu.com/security/CVE-2025-40350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run. Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it. To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40347", "url": "https://ubuntu.com/security/CVE-2025-40347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: fix the deadlock of enetc_mdio_lock After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock: enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdio After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang. Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40243", "url": "https://ubuntu.com/security/CVE-2025-40243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits() The syzbot reported issue in hfs_find_set_zero_bits(): ===================================================== BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408 hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353 __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151 block_write_begin fs/buffer.c:2262 [inline] cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 cont_expand_zero fs/buffer.c:2528 [inline] cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654 notify_change+0x1993/0x1aa0 fs/attr.c:552 do_truncate+0x28f/0x310 fs/open.c:68 do_ftruncate+0x698/0x730 fs/open.c:195 do_sys_ftruncate fs/open.c:210 [inline] __do_sys_ftruncate fs/open.c:215 [inline] __se_sys_ftruncate fs/open.c:213 [inline] __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213 x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354 kmalloc_noprof include/linux/slab.h:905 [inline] hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337 get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681 get_tree_bdev+0x38/0x50 fs/super.c:1704 hfs_get_tree+0x35/0x40 fs/hfs/super.c:388 vfs_get_tree+0xb0/0x5c0 fs/super.c:1804 do_new_mount+0x738/0x1610 fs/namespace.c:3902 path_mount+0x6db/0x1e90 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427 x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 ===================================================== The HFS_SB(sb)->bitmap buffer is allocated in hfs_mdb_get(): HFS_SB(sb)->bitmap = kmalloc(8192, GFP_KERNEL); Finally, it can trigger the reported issue because kmalloc() doesn't clear the allocated memory. If allocated memory contains only zeros, then everything will work pretty fine. But if the allocated memory contains the \"garbage\", then it can affect the bitmap operations and it triggers the reported issue. This patch simply exchanges the kmalloc() on kzalloc() with the goal to guarantee the correctness of bitmap operations. Because, newly created allocation bitmap should have all available blocks free. Potentially, initialization bitmap's read operation could not fill the whole allocated memory and \"garbage\" in the not initialized memory will be the reason of volume coruptions and file system driver bugs.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40351", "url": "https://ubuntu.com/security/CVE-2025-40351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat() The syzbot reported issue in hfsplus_delete_cat(): [ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] __se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40349", "url": "https://ubuntu.com/security/CVE-2025-40349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: validate record offset in hfsplus_bmap_alloc hfsplus_bmap_alloc can trigger a crash if a record offset or length is larger than node_size [ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0 [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183 [ 15.265949] [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary) [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 15.266167] Call Trace: [ 15.266168] [ 15.266169] dump_stack_lvl+0x53/0x70 [ 15.266173] print_report+0xd0/0x660 [ 15.266181] kasan_report+0xce/0x100 [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0 [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0 [ 15.266217] hfsplus_brec_insert+0x870/0xb00 [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570 [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910 [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200 [ 15.266233] hfsplus_file_extend+0x5a7/0x1000 [ 15.266237] hfsplus_get_block+0x12b/0x8c0 [ 15.266238] __block_write_begin_int+0x36b/0x12c0 [ 15.266251] block_write_begin+0x77/0x110 [ 15.266252] cont_write_begin+0x428/0x720 [ 15.266259] hfsplus_write_begin+0x51/0x100 [ 15.266262] cont_write_begin+0x272/0x720 [ 15.266270] hfsplus_write_begin+0x51/0x100 [ 15.266274] generic_perform_write+0x321/0x750 [ 15.266285] generic_file_write_iter+0xc3/0x310 [ 15.266289] __kernel_write_iter+0x2fd/0x800 [ 15.266296] dump_user_range+0x2ea/0x910 [ 15.266301] elf_core_dump+0x2a94/0x2ed0 [ 15.266320] vfs_coredump+0x1d85/0x45e0 [ 15.266349] get_signal+0x12e3/0x1990 [ 15.266357] arch_do_signal_or_restart+0x89/0x580 [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110 [ 15.266364] asm_exc_page_fault+0x26/0x30 [ 15.266366] RIP: 0033:0x41bd35 [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283 [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000 [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100 [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000 [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000 [ 15.266376] When calling hfsplus_bmap_alloc to allocate a free node, this function first retrieves the bitmap from header node and map node using node->page together with the offset and length from hfs_brec_lenoff ``` len = hfs_brec_lenoff(node, 2, &off16); off = off16; off += node->page_offset; pagep = node->page + (off >> PAGE_SHIFT); data = kmap_local_page(*pagep); ``` However, if the retrieved offset or length is invalid(i.e. exceeds node_size), the code may end up accessing pages outside the allocated range for this node. This patch adds proper validation of both offset and length before use, preventing out-of-bounds page access. Move is_bnode_offset_valid and check_and_correct_requested_length to hfsplus_fs.h, as they may be required by other functions.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40244", "url": "https://ubuntu.com/security/CVE-2025-40244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() The syzbot reported issue in __hfsplus_ext_cache_extent(): [ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0 [ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.196959][ T9350] cont_write_begin+0x1000/0x1950 [ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.199393][ T9350] vfs_write+0xb0f/0x14e0 [ 70.199771][ T9350] ksys_write+0x23e/0x490 [ 70.200149][ T9350] __x64_sys_write+0x97/0xf0 [ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.202054][ T9350] [ 70.202279][ T9350] Uninit was created at: [ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80 [ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0 [ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0 [ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.205074][ T9350] cont_write_begin+0x1000/0x1950 [ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.207552][ T9350] vfs_write+0xb0f/0x14e0 [ 70.207961][ T9350] ksys_write+0x23e/0x490 [ 70.208375][ T9350] __x64_sys_write+0x97/0xf0 [ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.210230][ T9350] [ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5 [ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.212115][ T9350] ===================================================== [ 70.212734][ T9350] Disabling lock debugging due to kernel taint [ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ... [ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5 [ 70.214679][ T9350] Tainted: [B]=BAD_PAGE [ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.215999][ T9350] Call Trace: [ 70.216309][ T9350] [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0 [ 70.217025][ T9350] dump_stack+0x1e/0x30 [ 70.217421][ T9350] panic+0x502/0xca0 [ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ... kernel :[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 set ... [ 70.221254][ T9350] ? __msan_warning+0x96/0x120 [ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0 [ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0 [ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0 [ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950 [ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130 [ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060 [ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460 [ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0 [ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0 [ 70.228997][ T9350] ? ksys_write+0x23e/0x490 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40245", "url": "https://ubuntu.com/security/CVE-2025-40245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nios2: ensure that memblock.current_limit is set when setting pfn limits On nios2, with CONFIG_FLATMEM set, the kernel relies on memblock_get_current_limit() to determine the limits of mem_map, in particular for max_low_pfn. Unfortunately, memblock.current_limit is only default initialized to MEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading to situations where max_low_pfn can erroneously exceed the value of max_pfn and, thus, the valid range of available DRAM. This can in turn cause kernel-level paging failures, e.g.: [ 76.900000] Unable to handle kernel paging request at virtual address 20303000 [ 76.900000] ea = c0080890, ra = c000462c, cause = 14 [ 76.900000] Kernel panic - not syncing: Oops [ 76.900000] ---[ end Kernel panic - not syncing: Oops ]--- This patch fixes this by pre-calculating memblock.current_limit based on the upper limits of the available memory ranges via adjust_lowmem_bounds, a simplified version of the equivalent implementation within the arm architecture.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40105", "url": "https://ubuntu.com/security/CVE-2025-40105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: Don't leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (\"VFS: don't keep disconnected dentries on d_anon\") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are \"leaked\". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous \"Busy inodes after unmount\" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40092", "url": "https://ubuntu.com/security/CVE-2025-40092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Refactor bind path to use __free() After an bind/unbind cycle, the ncm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40101", "url": "https://ubuntu.com/security/CVE-2025-40101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST At the end of btrfs_load_block_group_zone_info() the first thing we do is to ensure that if the mapping type is not a SINGLE one and there is no RAID stripe tree, then we return early with an error. Doing that, though, prevents the code from running the last calls from this function which are about freeing memory allocated during its run. Hence, in this case, instead of returning early, we set the ret value and fall through the rest of the cleanup code.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40166", "url": "https://ubuntu.com/security/CVE-2025-40166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Check GuC running state before deregistering exec queue In normal operation, a registered exec queue is disabled and deregistered through the GuC, and freed only after the GuC confirms completion. However, if the driver is forced to unbind while the exec queue is still running, the user may call exec_destroy() after the GuC has already been stopped and CT communication disabled. In this case, the driver cannot receive a response from the GuC, preventing proper cleanup of exec queue resources. Fix this by directly releasing the resources when GuC is not running. Here is the failure dmesg log: \" [ 468.089581] ---[ end trace 0000000000000000 ]--- [ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535) [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535 [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1 [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1) [ 468.092716] ------------[ cut here ]------------ [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe] \" v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled(). As CT may go down and come back during VF migration. (cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40104", "url": "https://ubuntu.com/security/CVE-2025-40104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ixgbevf: fix mailbox API compatibility by negotiating supported features There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API. This convention has been broken since introducing API 1.4. Commit 0062e7cc955e (\"ixgbevf: add VF IPsec offload code\") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself. Commit 339f28964147 (\"ixgbevf: Add support for new mailbox communication between PF and VF\") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes. The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 (\"ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5\"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX. To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox. New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op. Features negotiation mechanism gives possibility to be extended with new features when needed in the future.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40087", "url": "https://ubuntu.com/security/CVE-2025-40087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Define a proc_layoutcommit for the FlexFiles layout type Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40196", "url": "https://ubuntu.com/security/CVE-2025-40196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to \"events_unbound\" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance \"writeback\" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40088", "url": "https://ubuntu.com/security/CVE-2025-40088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp() The hfsplus_strcasecmp() logic can trigger the issue: [ 117.317703][ T9855] ================================================================== [ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490 [ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855 [ 117.319577][ T9855] [ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full) [ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 117.319783][ T9855] Call Trace: [ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0 [ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10 [ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0 [ 117.319816][ T9855] ? lock_release+0x4b/0x3e0 [ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40 [ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319842][ T9855] print_report+0x17e/0x7e0 [ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319862][ T9855] ? __phys_addr+0xd3/0x180 [ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319876][ T9855] kasan_report+0x147/0x180 [ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490 [ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10 [ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0 [ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470 [ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10 [ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10 [ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510 [ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10 [ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510 [ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0 [ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120 [ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890 [ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10 [ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0 [ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80 [ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10 [ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100 [ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150 [ 117.320034][ T9855] __lookup_slow+0x297/0x3d0 [ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10 [ 117.320045][ T9855] ? down_read+0x1ad/0x2e0 [ 117.320055][ T9855] lookup_slow+0x53/0x70 [ 117.320065][ T9855] walk_component+0x2f0/0x430 [ 117.320073][ T9855] path_lookupat+0x169/0x440 [ 117.320081][ T9855] filename_lookup+0x212/0x590 [ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10 [ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290 [ 117.320105][ T9855] ? getname_flags+0x1e5/0x540 [ 117.320112][ T9855] user_path_at+0x3a/0x60 [ 117.320117][ T9855] __x64_sys_umount+0xee/0x160 [ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10 [ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0 [ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0 [ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0 [ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07 [ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08 [ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40085", "url": "https://ubuntu.com/security/CVE-2025-40085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card In try_to_register_card(), the return value of usb_ifnum_to_if() is passed directly to usb_interface_claimed() without a NULL check, which will lead to a NULL pointer dereference when creating an invalid USB audio device. Fix this by adding a check to ensure the interface pointer is valid before passing it to usb_interface_claimed().", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40172", "url": "https://ubuntu.com/security/CVE-2025-40172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() Currently, if find_and_map_user_pages() takes a DMA xfer request from the user with a length field set to 0, or in a rare case, the host receives QAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size is equal to the requested transaction size, the function will return 0 before allocating an sgt or setting the fields of the dma_xfer struct. In that case, encode_addr_size_pairs() will try to access the sgt which will lead to a general protection fault. Return an EINVAL in case the user provides a zero-sized ALP, or the device requests continuation after all of the bytes have been transferred.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40176", "url": "https://ubuntu.com/security/CVE-2025-40176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: wait for pending async decryptions if tls_strp_msg_hold fails Async decryption calls tls_strp_msg_hold to create a clone of the input skb to hold references to the memory it uses. If we fail to allocate that clone, proceeding with async decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, wait for all pending decryption requests.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40173", "url": "https://ubuntu.com/security/CVE-2025-40173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ip6_tunnel: Prevent perpetual tunnel growth Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd (\"net: ip_tunnel: prevent perpetual headroom growth\"), ipv6 tunnel yet increases the headroom without any ceiling. Reflect ipv4 tunnel headroom adjustment limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-specific patch and a reproducer.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40095", "url": "https://ubuntu.com/security/CVE-2025-40095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Refactor bind path to use __free() After an bind/unbind cycle, the rndis->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40094", "url": "https://ubuntu.com/security/CVE-2025-40094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_acm: Refactor bind path to use __free() After an bind/unbind cycle, the acm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec gs_free_req+0x30/0x44 acm_bind+0x1b8/0x1f4 usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40093", "url": "https://ubuntu.com/security/CVE-2025-40093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ecm: Refactor bind path to use __free() After an bind/unbind cycle, the ecm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40165", "url": "https://ubuntu.com/security/CVE-2025-40165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: m2m: Fix streaming cleanup on release If streamon/streamoff calls are imbalanced, such as when exiting an application with Ctrl+C when streaming, the m2m usage_count will never reach zero and the ISI channel won't be freed. Besides from that, if the input line width is more than 2K, it will trigger a WARN_ON(): [ 59.222120] ------------[ cut here ]------------ [ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654 [ 59.238569] Modules linked in: ap1302 [ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT [ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT) [ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120 [ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120 [ 59.275047] sp : ffff8000848c3b40 [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00 [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001 [ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780 [ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000 [ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c [ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30 [ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420 [ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000 [ 59.349590] Call trace: [ 59.352025] mxc_isi_channel_chain+0xa4/0x120 (P) [ 59.356722] mxc_isi_m2m_streamon+0x160/0x20c [ 59.361072] v4l_streamon+0x24/0x30 [ 59.364556] __video_do_ioctl+0x40c/0x4a0 [ 59.368560] video_usercopy+0x2bc/0x690 [ 59.372382] video_ioctl2+0x18/0x24 [ 59.375857] v4l2_ioctl+0x40/0x60 [ 59.379168] __arm64_sys_ioctl+0xac/0x104 [ 59.383172] invoke_syscall+0x48/0x104 [ 59.386916] el0_svc_common.constprop.0+0xc0/0xe0 [ 59.391613] do_el0_svc+0x1c/0x28 [ 59.394915] el0_svc+0x34/0xf4 [ 59.397966] el0t_64_sync_handler+0xa0/0xe4 [ 59.402143] el0t_64_sync+0x198/0x19c [ 59.405801] ---[ end trace 0000000000000000 ]--- Address this issue by moving the streaming preparation and cleanup to the vb2 .prepare_streaming() and .unprepare_streaming() operations. This also simplifies the driver by allowing direct usage of the v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40096", "url": "https://ubuntu.com/security/CVE-2025-40096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free. Interestingly this bug appears to have been present ever since commit ebd5f74255b9 (\"drm/sched: Add dependency tracking\"), since the code back then looked like this: drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]); Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it. The bug was then only noticed and fixed after commit 9c2ba265352a (\"drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2\") landed, with its fixup of commit 4eaf02d6076c (\"drm/scheduler: fix drm_sched_job_add_implicit_dependencies\"). At that point it was a slightly different flavour of a double free, which commit 963d0b356935 (\"drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder\") noticed and attempted to fix. But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case. As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain. While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.", "cve_priority": "low", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40099", "url": "https://ubuntu.com/security/CVE-2025-40099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: parse_dfs_referrals: prevent oob on malformed input Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS - reply smaller than sizeof(struct get_dfs_referral_rsp) - reply with number of referrals smaller than NumberOfReferrals in the header Processing of such replies will cause oob. Return -EINVAL error on such replies to prevent oob-s.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40100", "url": "https://ubuntu.com/security/CVE-2025-40100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40167", "url": "https://ubuntu.com/security/CVE-2025-40167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: detect invalid INLINE_DATA + EXTENTS flag combination syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal. The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 This is an invalid combination since an inode should have either: - INLINE_DATA: data stored directly in the inode - EXTENTS: data stored in extent-mapped blocks Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40198", "url": "https://ubuntu.com/security/CVE-2025-40198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40159", "url": "https://ubuntu.com/security/CVE-2025-40159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Harden userspace-supplied xdp_desc validation Turned out certain clearly invalid values passed in xdp_desc from userspace can pass xp_{,un}aligned_validate_desc() and then lead to UBs or just invalid frames to be queued for xmit. desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len can cause positive integer overflow and wraparound, the same way low enough desc->addr with a non-zero pool->tx_metadata_len can cause negative integer overflow. Both scenarios can then pass the validation successfully. This doesn't happen with valid XSk applications, but can be used to perform attacks. Always promote desc->len to ``u64`` first to exclude positive overflows of it. Use explicit check_{add,sub}_overflow() when validating desc->addr (which is ``u64`` already). bloat-o-meter reports a little growth of the code size: add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44) Function old new delta xskq_cons_peek_desc 299 330 +31 xsk_tx_peek_release_desc_batch 973 1002 +29 xsk_generic_xmit 3148 3132 -16 but hopefully this doesn't hurt the performance much.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40221", "url": "https://ubuntu.com/security/CVE-2025-40221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: mg4b: fix uninitialized iio scan data Fix potential leak of uninitialized stack data to userspace by ensuring that the `scan` structure is zeroed before use.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40180", "url": "https://ubuntu.com/security/CVE-2025-40180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40178", "url": "https://ubuntu.com/security/CVE-2025-40178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pid: Add a judgment for ns null in pid_nr_ns __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: \tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058 \tMem abort info: \tESR = 0x0000000096000007 \tEC = 0x25: DABT (current EL), IL = 32 bits \tSET = 0, FnV = 0 \tEA = 0, S1PTW = 0 \tFSC = 0x07: level 3 translation fault \tData abort info: \tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 \tCM = 0, WnR = 0, TnD = 0, TagAccess = 0 \tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 \t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 \tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) \tpc : __task_pid_nr_ns+0x74/0xd0 \tlr : __task_pid_nr_ns+0x24/0xd0 \tsp : ffffffc08001bd10 \tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 \tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 \tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 \tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 \tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc \tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 \tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 \tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 \tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc \tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 \tCall trace: \t__task_pid_nr_ns+0x74/0xd0 \t... \t__handle_irq_event_percpu+0xd4/0x284 \thandle_irq_event+0x48/0xb0 \thandle_fasteoi_irq+0x160/0x2d8 \tgeneric_handle_domain_irq+0x44/0x60 \tgic_handle_irq+0x4c/0x114 \tcall_on_irq_stack+0x3c/0x74 \tdo_interrupt_handler+0x4c/0x84 \tel1_interrupt+0x34/0x58 \tel1h_64_irq_handler+0x18/0x24 \tel1h_64_irq+0x68/0x6c \taccount_kernel_stack+0x60/0x144 \texit_task_stack_account+0x1c/0x80 \tdo_exit+0x7e4/0xaf8 \t... \tget_signal+0x7bc/0x8d8 \tdo_notify_resume+0x128/0x828 \tel0_svc+0x6c/0x70 \tel0t_64_sync_handler+0x68/0xbc \tel0t_64_sync+0x1a8/0x1ac \tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) \t---[ end trace 0000000000000000 ]--- \tKernel panic - not syncing: Oops: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40202", "url": "https://ubuntu.com/security/CVE-2025-40202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Rework user message limit handling The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free. Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine. It's a lot cleaner and safer.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40032", "url": "https://ubuntu.com/security/CVE-2025-40032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 [mani: trimmed the stack trace]", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40038", "url": "https://ubuntu.com/security/CVE-2025-40038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b Note, this is essentially a reapply of commit 5c30e8101e8d (\"KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid\"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons).", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40042", "url": "https://ubuntu.com/security/CVE-2025-40042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race condition in kprobe initialization causing NULL pointer dereference There is a critical race condition in kprobe initialization that can lead to NULL pointer dereference and kernel crash. [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000 ... [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO) [1135630.269239] pc : kprobe_perf_func+0x30/0x260 [1135630.277643] lr : kprobe_dispatcher+0x44/0x60 [1135630.286041] sp : ffffaeff4977fa40 [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400 [1135630.302837] x27: 0000000000000000 x26: 0000000000000000 [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528 [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50 [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50 [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000 [1135630.349985] x17: 0000000000000000 x16: 0000000000000000 [1135630.359285] x15: 0000000000000000 x14: 0000000000000000 [1135630.368445] x13: 0000000000000000 x12: 0000000000000000 [1135630.377473] x11: 0000000000000000 x10: 0000000000000000 [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000 [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000 [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000 [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006 [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000 [1135630.429410] Call trace: [1135630.434828] kprobe_perf_func+0x30/0x260 [1135630.441661] kprobe_dispatcher+0x44/0x60 [1135630.448396] aggr_pre_handler+0x70/0xc8 [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0 [1135630.462435] brk_handler+0xbc/0xd8 [1135630.468437] do_debug_exception+0x84/0x138 [1135630.475074] el1_dbg+0x18/0x8c [1135630.480582] security_file_permission+0x0/0xd0 [1135630.487426] vfs_write+0x70/0x1c0 [1135630.493059] ksys_write+0x5c/0xc8 [1135630.498638] __arm64_sys_write+0x24/0x30 [1135630.504821] el0_svc_common+0x78/0x130 [1135630.510838] el0_svc_handler+0x38/0x78 [1135630.516834] el0_svc+0x8/0x1b0 kernel/trace/trace_kprobe.c: 1308 0xffff3df8995039ec : ldr x21, [x24,#120] include/linux/compiler.h: 294 0xffff3df8995039f0 : ldr x1, [x21,x0] kernel/trace/trace_kprobe.c 1308: head = this_cpu_ptr(call->perf_events); 1309: if (hlist_empty(head)) 1310: \treturn 0; crash> struct trace_event_call -o struct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ... } crash> struct trace_event_call ffffaf015340e528 struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ... } Race Condition Analysis: The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)← KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL) Problem: 1. CPU0 executes (1) assigning tp_event->perf_events = list 2. CPU0 executes (2) enabling kprobe functionality via class->reg() 3. CPU1 triggers and reaches kprobe_dispatcher 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed) 5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULL CPU1 sees that kprobe functionality is enabled but does not see that perf_events has been assigned. Add pairing read an ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40200", "url": "https://ubuntu.com/security/CVE-2025-40200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: reject negative file sizes in squashfs_read_inode() Syskaller reports a \"WARNING in ovl_copy_up_file\" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip@squashfs.org.uk: only need to check 64 bit quantity]", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40179", "url": "https://ubuntu.com/security/CVE-2025-40179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: verify orphan file size is not too big In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but large orphan files.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40218", "url": "https://ubuntu.com/security/CVE-2025-40218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr: do not repeat pte_offset_map_lock() until success DAMON's virtual address space operation set implementation (vaddr) calls pte_offset_map_lock() inside the page table walk callback function. This is for reading and writing page table accessed bits. If pte_offset_map_lock() fails, it retries by returning the page table walk callback function with ACTION_AGAIN. pte_offset_map_lock() can continuously fail if the target is a pmd migration entry, though. Hence it could cause an infinite page table walk if the migration cannot be done until the page table walk is finished. This indeed caused a soft lockup when CPU hotplugging and DAMON were running in parallel. Avoid the infinite loop by simply not retrying the page table walk. DAMON is promising only a best-effort accuracy, so missing access to such pages is no problem.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40219", "url": "https://ubuntu.com/security/CVE-2025-40219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 (\"PCI: Add global pci_lock_rescan_remove()\") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc (\"PCI/IOV: Factor out sriov_add_vfs()\") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 \t00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 \t0000000000000001 0000000000000000 0000000000000000 0000000180692828 \t00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40193", "url": "https://ubuntu.com/security/CVE-2025-40193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xtensa: simdisk: add input size check in proc_write_simdisk A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash. This follows the same pattern as commit ee76746387f6 (\"netdevsim: prevent bad user input in nsim_dev_health_break_write()\")", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40204", "url": "https://ubuntu.com/security/CVE-2025-40204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40192", "url": "https://ubuntu.com/security/CVE-2025-40192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"ipmi: fix msg stack when IPMI is disconnected\" This reverts commit c608966f3f9c2dca596967501d00753282b395fc. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40188", "url": "https://ubuntu.com/security/CVE-2025-40188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pwm: berlin: Fix wrong register in suspend/resume The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40201", "url": "https://ubuntu.com/security/CVE-2025-40201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40194", "url": "https://ubuntu.com/security/CVE-2025-40194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40205", "url": "https://ubuntu.com/security/CVE-2025-40205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid potential out-of-bounds in btrfs_encode_fh() The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40160", "url": "https://ubuntu.com/security/CVE-2025-40160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/events: Return -EEXIST for bound VIRQs Change find_virq() to return -EEXIST when a VIRQ is bound to a different CPU than the one passed in. With that, remove the BUG_ON() from bind_virq_to_irq() to propogate the error upwards. Some VIRQs are per-cpu, but others are per-domain or global. Those must be bound to CPU0 and can then migrate elsewhere. The lookup for per-domain and global will probably fail when migrated off CPU 0, especially when the current CPU is tracked. This now returns -EEXIST instead of BUG_ON(). A second call to bind a per-domain or global VIRQ is not expected, but make it non-fatal to avoid trying to look up the irq, since we don't know which per_cpu(virq_to_irq) it will be in.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40206", "url": "https://ubuntu.com/security/CVE-2025-40206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_objref: validate objref and objrefmap expressions Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls: BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12) [...] Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 [...] Implement objref and objrefmap expression validate functions. Currently, only NFT_OBJECT_SYNPROXY object type requires validation. This will also handle a jump to a chain using a synproxy object from the OUTPUT hook. Now when trying to reference a synproxy object in the OUTPUT hook, nft will produce the following error: synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40183", "url": "https://ubuntu.com/security/CVE-2025-40183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6} Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40187", "url": "https://ubuntu.com/security/CVE-2025-40187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40111", "url": "https://ubuntu.com/security/CVE-2025-40111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix Use-after-free in validation Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.", "cve_priority": "medium", "cve_public_date": "2025-11-12 02:15:00 UTC" }, { "cve": "CVE-2025-40110", "url": "https://ubuntu.com/security/CVE-2025-40110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a null-ptr access in the cursor snooper Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it. vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean \"no surface\", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it. Fixes unchecked null-ptr reference in the snooping code.", "cve_priority": "medium", "cve_public_date": "2025-11-12 02:15:00 UTC" }, { "cve": "CVE-2025-40001", "url": "https://ubuntu.com/security/CVE-2025-40001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mvsas: Fix use-after-free bugs in mvs_work_queue During the detaching of Marvell's SAS/SATA controller, the original code calls cancel_delayed_work() in mvs_free() to cancel the delayed work item mwq->work_q. However, if mwq->work_q is already running, the cancel_delayed_work() may fail to cancel it. This can lead to use-after-free scenarios where mvs_free() frees the mvs_info while mvs_work_queue() is still executing and attempts to access the already-freed mvs_info. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work item completes before the mvs_info is deallocated. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2025-10-18 08:15:00 UTC" }, { "cve": "CVE-2025-40207", "url": "https://ubuntu.com/security/CVE-2025-40207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try() v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40031", "url": "https://ubuntu.com/security/CVE-2025-40031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: fix register_shm_helper() In register_shm_helper(), fix incorrect error handling for a call to iov_iter_extract_pages(). A case is missing for when iov_iter_extract_pages() only got some pages and return a number larger than 0, but not the requested amount. This fixes a possible NULL pointer dereference following a bad input from ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40037", "url": "https://ubuntu.com/security/CVE-2025-40037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: simplefb: Fix use after free in simplefb_detach_genpds() The pm_domain cleanup can not be devres managed as it uses struct simplefb_par which is allocated within struct fb_info by framebuffer_alloc(). This allocation is explicitly freed by unregister_framebuffer() in simplefb_remove(). Devres managed cleanup runs after the device remove call and thus can no longer access struct simplefb_par. Call simplefb_detach_genpds() explicitly from simplefb_destroy() like the cleanup functions for clocks and regulators. Fixes an use after free on M2 Mac mini during aperture_remove_conflicting_devices() using the downstream asahi kernel with Debian's kernel config. For unknown reasons this started to consistently dereference an invalid pointer in v6.16.3 based kernels. [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220 [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227 [ 6.750697] [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT) [ 6.752189] Call trace: [ 6.752190] show_stack+0x34/0x98 (C) [ 6.752194] dump_stack_lvl+0x60/0x80 [ 6.752197] print_report+0x17c/0x4d8 [ 6.752201] kasan_report+0xb4/0x100 [ 6.752206] __asan_report_load4_noabort+0x20/0x30 [ 6.752209] simplefb_detach_genpds+0x58/0x220 [ 6.752213] devm_action_release+0x50/0x98 [ 6.752216] release_nodes+0xd0/0x2c8 [ 6.752219] devres_release_all+0xfc/0x178 [ 6.752221] device_unbind_cleanup+0x28/0x168 [ 6.752224] device_release_driver_internal+0x34c/0x470 [ 6.752228] device_release_driver+0x20/0x38 [ 6.752231] bus_remove_device+0x1b0/0x380 [ 6.752234] device_del+0x314/0x820 [ 6.752238] platform_device_del+0x3c/0x1e8 [ 6.752242] platform_device_unregister+0x20/0x50 [ 6.752246] aperture_detach_platform_device+0x1c/0x30 [ 6.752250] aperture_detach_devices+0x16c/0x290 [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50 ... [ 6.752343] [ 6.967409] Allocated by task 62: [ 6.970724] kasan_save_stack+0x3c/0x70 [ 6.974560] kasan_save_track+0x20/0x40 [ 6.978397] kasan_save_alloc_info+0x40/0x58 [ 6.982670] __kasan_kmalloc+0xd4/0xd8 [ 6.986420] __kmalloc_noprof+0x194/0x540 [ 6.990432] framebuffer_alloc+0xc8/0x130 [ 6.994444] simplefb_probe+0x258/0x2378 ... [ 7.054356] [ 7.055838] Freed by task 227: [ 7.058891] kasan_save_stack+0x3c/0x70 [ 7.062727] kasan_save_track+0x20/0x40 [ 7.066565] kasan_save_free_info+0x4c/0x80 [ 7.070751] __kasan_slab_free+0x6c/0xa0 [ 7.074675] kfree+0x10c/0x380 [ 7.077727] framebuffer_release+0x5c/0x90 [ 7.081826] simplefb_destroy+0x1b4/0x2c0 [ 7.085837] put_fb_info+0x98/0x100 [ 7.089326] unregister_framebuffer+0x178/0x320 [ 7.093861] simplefb_remove+0x3c/0x60 [ 7.097611] platform_remove+0x60/0x98 [ 7.101361] device_remove+0xb8/0x160 [ 7.105024] device_release_driver_internal+0x2fc/0x470 [ 7.110256] device_release_driver+0x20/0x38 [ 7.114529] bus_remove_device+0x1b0/0x380 [ 7.118628] device_del+0x314/0x820 [ 7.122116] platform_device_del+0x3c/0x1e8 [ 7.126302] platform_device_unregister+0x20/0x50 [ 7.131012] aperture_detach_platform_device+0x1c/0x30 [ 7.136157] aperture_detach_devices+0x16c/0x290 [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50 ...", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40047", "url": "https://ubuntu.com/security/CVE-2025-40047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: always prune wait queue entry in io_waitid_wait() For a successful return, always remove our entry from the wait queue entry list. Previously this was skipped if a cancelation was in progress, but this can race with another invocation of the wait queue entry callback.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40057", "url": "https://ubuntu.com/security/CVE-2025-40057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Add a upper bound on max_vclocks syzbot reported WARNING in max_vclocks_store. This occurs when the argument max is too large for kcalloc to handle. Extend the guard to guard against values that are too large for kcalloc", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40058", "url": "https://ubuntu.com/security/CVE-2025-40058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Disallow dirty tracking if incoherent page walk Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work. The Intel VT-d specification, Section 3.10 \"Snoop Behavior\" states: \"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault.\" To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40059", "url": "https://ubuntu.com/security/CVE-2025-40059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: Fix incorrect handling for return value of devm_kzalloc The return value of devm_kzalloc could be an null pointer, use \"!desc.pdata\" to fix incorrect handling return value of devm_kzalloc.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40155", "url": "https://ubuntu.com/security/CVE-2025-40155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: debugfs: Fix legacy mode page table dump logic In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490 ... Avoid walking the page table if TT is not 00b or 01b.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40079", "url": "https://ubuntu.com/security/CVE-2025-40079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Sign extend struct ops return values properly The ns_bpf_qdisc selftest triggers a kernel panic: Unable to handle kernel paging request at virtual address ffffffffa38dbf58 Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000 [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000 Oops [#1] Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)] CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G W OE 6.17.0-rc1-g2465bb83e0b4 #1 NONE Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024 epc : __qdisc_run+0x82/0x6f0 ra : __qdisc_run+0x6e/0x6f0 epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550 gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180 t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0 s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001 a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000 a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049 s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000 s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0 s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000 s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000 t5 : 0000000000000000 t6 : ff60000093a6a8b6 status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d [] __qdisc_run+0x82/0x6f0 [] __dev_queue_xmit+0x4c0/0x1128 [] neigh_resolve_output+0xd0/0x170 [] ip6_finish_output2+0x226/0x6c8 [] ip6_finish_output+0x10c/0x2a0 [] ip6_output+0x5e/0x178 [] ip6_xmit+0x29a/0x608 [] inet6_csk_xmit+0xe6/0x140 [] __tcp_transmit_skb+0x45c/0xaa8 [] tcp_connect+0x9ce/0xd10 [] tcp_v6_connect+0x4ac/0x5e8 [] __inet_stream_connect+0xd8/0x318 [] inet_stream_connect+0x3e/0x68 [] __sys_connect_file+0x50/0x88 [] __sys_connect+0x96/0xc8 [] __riscv_sys_connect+0x20/0x30 [] do_trap_ecall_u+0x256/0x378 [] handle_exception+0x14a/0x156 Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709 ---[ end trace 0000000000000000 ]--- The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires RISC-V ABI. So let's sign extend struct ops return values according to the function model and RISC-V ABI([0]). [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40000", "url": "https://ubuntu.com/security/CVE-2025-40000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait() There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to access already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 It is a consequence of a race between the waiting and the signaling side of the completion: Waiting thread Completing thread rtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40026", "url": "https://ubuntu.com/security/CVE-2025-40026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended \"recipient\") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-10-28 10:15:00 UTC" }, { "cve": "CVE-2025-40027", "url": "https://ubuntu.com/security/CVE-2025-40027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix double req put in p9_fd_cancelled Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__list_del_entry include/linux/list.h:137 [inline] RIP: 0010:list_del include/linux/list.h:148 [inline] RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734 Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ... Commit 74d6a5d56629 (\"9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work\") fixes a concurrency issue in the 9p filesystem client where the req_list could be deleted simultaneously by both p9_read_work and p9_fd_cancelled functions, but for the case where req->status equals REQ_STATUS_RCVD. Update the check for req->status in p9_fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [updated the check from status == RECV || status == ERROR to status != SENT]", "cve_priority": "medium", "cve_public_date": "2025-10-28 10:15:00 UTC" }, { "cve": "CVE-2025-40109", "url": "https://ubuntu.com/security/CVE-2025-40109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present Ensure that set_ent is always set since only drbg provides it.", "cve_priority": "medium", "cve_public_date": "2025-11-09 05:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40107", "url": "https://ubuntu.com/security/CVE-2025-40107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d (\"can: mcp251x: fix resume from sleep before interface was brought up\"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-11-03 13:15:00 UTC" }, { "cve": "CVE-2025-39995", "url": "https://ubuntu.com/security/CVE-2025-39995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe The state->timer is a cyclic timer that schedules work_i2c_poll and delayed_work_enable_hotplug, while rearming itself. Using timer_delete() fails to guarantee the timer isn't still running when destroyed, similarly cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has terminated if already executing. During probe failure after timer initialization, these may continue running as orphans and reference the already-freed tc358743_state object through tc358743_irq_poll_timer. The following is the trace captured by KASAN. BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace timer_delete() with timer_delete_sync() and cancel_delayed_work() with cancel_delayed_work_sync() to ensure proper termination of timer and work items before resource cleanup. This bug was initially identified through static analysis. For reproduction and testing, I created a functional emulation of the tc358743 device via a kernel module and introduced faults through the debugfs interface.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39994", "url": "https://ubuntu.com/security/CVE-2025-39994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tuner: xc5000: Fix use-after-free in xc5000_release The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was initially identified through static analysis. [hverkuil: fix typo in Subject: tunner -> tuner]", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39991", "url": "https://ubuntu.com/security/CVE-2025-39991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39992", "url": "https://ubuntu.com/security/CVE-2025-39992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap())\t\t\tswapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> \tcopy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). \t\t\t\t 4) swapoff is tried on the \t\t\t\t\t'mm' added to the 'mmlist' as \t\t\t\t\tpart of the 2. \t\t\t\t 5) unuse_mm(), that iterates \t\t\t\t\tthrough the vma's of this 'mm' \t\t\t\t\twill hit the non-NULL zero entry \t\t\t\t\tand operating on this zero entry \t\t\t\t\tas a vma is resulting into the \t\t\t\t\toops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40013", "url": "https://ubuntu.com/security/CVE-2025-40013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: audioreach: fix potential null pointer dereference It is possible that the topology parsing function audioreach_widget_load_module_common() could return NULL or an error pointer. Add missing NULL check so that we do not dereference it.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39996", "url": "https://ubuntu.com/security/CVE-2025-39996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAF This is confirmed by a KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39998", "url": "https://ubuntu.com/security/CVE-2025-39998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: target_core_configfs: Add length check to avoid buffer overflow A buffer overflow arises from the usage of snprintf to write into the buffer \"buf\" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40009", "url": "https://ubuntu.com/security/CVE-2025-40009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: check p->vec_buf for NULL When the PAGEMAP_SCAN ioctl is invoked with vec_len = 0 reaches pagemap_scan_backout_range(), kernel panics with null-ptr-deref: [ 44.936808] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.937797] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 44.938391] CPU: 1 UID: 0 PID: 2480 Comm: reproducer Not tainted 6.17.0-rc6 #22 PREEMPT(none) [ 44.939062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.939935] RIP: 0010:pagemap_scan_thp_entry.isra.0+0x741/0xa80 [ 44.946828] Call Trace: [ 44.947030] [ 44.949219] pagemap_scan_pmd_entry+0xec/0xfa0 [ 44.952593] walk_pmd_range.isra.0+0x302/0x910 [ 44.954069] walk_pud_range.isra.0+0x419/0x790 [ 44.954427] walk_p4d_range+0x41e/0x620 [ 44.954743] walk_pgd_range+0x31e/0x630 [ 44.955057] __walk_page_range+0x160/0x670 [ 44.956883] walk_page_range_mm+0x408/0x980 [ 44.958677] walk_page_range+0x66/0x90 [ 44.958984] do_pagemap_scan+0x28d/0x9c0 [ 44.961833] do_pagemap_cmd+0x59/0x80 [ 44.962484] __x64_sys_ioctl+0x18d/0x210 [ 44.962804] do_syscall_64+0x5b/0x290 [ 44.963111] entry_SYSCALL_64_after_hwframe+0x76/0x7e vec_len = 0 in pagemap_scan_init_bounce_buffer() means no buffers are allocated and p->vec_buf remains set to NULL. This breaks an assumption made later in pagemap_scan_backout_range(), that page_region is always allocated for p->vec_buf_index. Fix it by explicitly checking p->vec_buf for NULL before dereferencing. Other sites that might run into same deref-issue are already (directly or transitively) protected by checking p->vec_buf. Note: From PAGEMAP_SCAN man page, it seems vec_len = 0 is valid when no output is requested and it's only the side effects caller is interested in, hence it passes check in pagemap_scan_get_args(). This issue was found by syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39973", "url": "https://ubuntu.com/security/CVE-2025-39973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: add validation for ring_len param The `ring_len` parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation. To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-38709", "url": "https://ubuntu.com/security/CVE-2025-38709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: loop: Avoid updating block size under exclusive owner Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39967", "url": "https://ubuntu.com/security/CVE-2025-39967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix integer overflow in fbcon_do_set_font Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters. The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying. Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40006", "url": "https://ubuntu.com/security/CVE-2025-40006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix folio is still mapped when deleted Migration may be raced with fallocating hole. remove_inode_single_folio will unmap the folio if the folio is still mapped. However, it's called without folio lock. If the folio is migrated and the mapped pte has been converted to migration entry, folio_mapped() returns false, and won't unmap it. Due to extra refcount held by remove_inode_single_folio, migration fails, restores migration entry to normal pte, and the folio is mapped again. As a result, we triggered BUG in filemap_unaccount_folio. The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):\"my_hugepage_file\" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380 Hold folio lock before checking if the folio is mapped to avold race with migration.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40008", "url": "https://ubuntu.com/security/CVE-2025-40008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kmsan: fix out-of-bounds access to shadow memory Running sha224_kunit on a KMSAN-enabled kernel results in a crash in kmsan_internal_set_shadow_origin(): BUG: unable to handle page fault for address: ffffbc3840291000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1810067 P4D 1810067 PUD 192d067 PMD 3c17067 PTE 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 81 Comm: kunit_try_catch Tainted: G N 6.17.0-rc3 #10 PREEMPT(voluntary) Tainted: [N]=TEST Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmsan_internal_set_shadow_origin+0x91/0x100 [...] Call Trace: __msan_memset+0xee/0x1a0 sha224_final+0x9e/0x350 test_hash_buffer_overruns+0x46f/0x5f0 ? kmsan_get_shadow_origin_ptr+0x46/0xa0 ? __pfx_test_hash_buffer_overruns+0x10/0x10 kunit_try_run_case+0x198/0xa00 This occurs when memset() is called on a buffer that is not 4-byte aligned and extends to the end of a guard page, i.e. the next page is unmapped. The bug is that the loop at the end of kmsan_internal_set_shadow_origin() accesses the wrong shadow memory bytes when the address is not 4-byte aligned. Since each 4 bytes are associated with an origin, it rounds the address and size so that it can access all the origins that contain the buffer. However, when it checks the corresponding shadow bytes for a particular origin, it incorrectly uses the original unrounded shadow address. This results in reads from shadow memory beyond the end of the buffer's shadow memory, which crashes when that memory is not mapped. To fix this, correctly align the shadow address before accessing the 4 shadow bytes corresponding to each origin.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40010", "url": "https://ubuntu.com/security/CVE-2025-40010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix potential null pointer dereference in afs_put_server afs_put_server() accessed server->debug_id before the NULL check, which could lead to a null pointer dereference. Move the debug_id assignment, ensuring we never dereference a NULL server pointer.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40021", "url": "https://ubuntu.com/security/CVE-2025-40021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: dynevent: Add a missing lockdown check on dynevent Since dynamic_events interface on tracefs is compatible with kprobe_events and uprobe_events, it should also check the lockdown status and reject if it is set.", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39968", "url": "https://ubuntu.com/security/CVE-2025-39968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: add max boundary check for VF filters There is no check for max filters that VF can request. Add it.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39969", "url": "https://ubuntu.com/security/CVE-2025-39969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix validation of VF state in get resources VF state I40E_VF_STATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources. Use I40E_VF_STATE_RESOURCES_LOADED that is set only in i40e_vc_get_vf_resources_msg() and cleared during reset.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39970", "url": "https://ubuntu.com/security/CVE-2025-39970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix input validation logic for action_meta Fix condition to check 'greater or equal' to prevent OOB dereference.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39971", "url": "https://ubuntu.com/security/CVE-2025-39971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39972", "url": "https://ubuntu.com/security/CVE-2025-39972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in i40e_validate_queue_map Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map().", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39977", "url": "https://ubuntu.com/security/CVE-2025-39977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent use-after-free during requeue-PI syzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL); In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization. This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section. Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated. Read futex_q::task before updating the requeue state, use it for the following wakeup.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40011", "url": "https://ubuntu.com/security/CVE-2025-40011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix null dereference in hdmi teardown pci_set_drvdata sets the value of pdev->driver_data to NULL, after which the driver_data obtained from the same dev is dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is extracted from it. To prevent this, swap these calls. Found by Linux Verification Center (linuxtesting.org) with Svacer.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39978", "url": "https://ubuntu.com/security/CVE-2025-39978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow() This code calls kfree_rcu(new_node, rcu) and then dereferences \"new_node\" and then dereferences it on the next line. Two lines later, we take a mutex so I don't think this is an RCU safe region. Re-order it to do the dereferences before queuing up the free.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39980", "url": "https://ubuntu.com/security/CVE-2025-39980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Forbid FDB status change while nexthop is in a group The kernel forbids the creation of non-FDB nexthop groups with FDB nexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops. And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops. However, as long as no routes are pointing to a non-FDB nexthop group, the kernel allows changing the type of a nexthop from FDB to non-FDB and vice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0 This configuration is invalid and can result in a NPD [1] since FDB nexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1 Fix by preventing nexthop FDB status change while the nexthop is in a group: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group. [1] BUG: kernel NULL pointer dereference, address: 00000000000003c0 [...] Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:fib_lookup_good_nhc+0x1e/0x80 [...] Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40024", "url": "https://ubuntu.com/security/CVE-2025-40024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost: Take a reference on the task in struct vhost_task. vhost_task_create() creates a task and keeps a reference to its task_struct. That task may exit early via a signal and its task_struct will be released. A pending vhost_task_wake() will then attempt to wake the task and access a task_struct which is no longer there. Acquire a reference on the task_struct while creating the thread and release the reference while the struct vhost_task itself is removed. If the task exits early due to a signal, then the vhost_task_wake() will still access a valid task_struct. The wake is safe and will be skipped in this case.", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39982", "url": "https://ubuntu.com/security/CVE-2025-39982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync This fixes the following UFA in hci_acl_create_conn_sync where a connection still pending is command submission (conn->state == BT_OPEN) maybe freed, also since this also can happen with the likes of hci_le_create_conn_sync fix it as well: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541 CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci3 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40020", "url": "https://ubuntu.com/security/CVE-2025-40020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: fix shift-out-of-bounds issue Explicitly uses a 64-bit constant when the number of bits used for its shifting is 32 (which is the case for PC CAN FD interfaces supported by this driver). [mkl: update subject, apply manually]", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39985", "url": "https://ubuntu.com/security/CVE-2025-39985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the mcba_usb driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on these lines: \tusb_msg.dlc = cf->len; \tmemcpy(usb_msg.data, cf->data, usb_msg.dlc); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39986", "url": "https://ubuntu.com/security/CVE-2025-39986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, sun4ican_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on this line: \tdlc = cf->len; Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs a couple line below when doing: \tfor (i = 0; i < dlc; i++) \t\twritel(cf->data[i], priv->base + (dreg + i * 4)); Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39987", "url": "https://ubuntu.com/security/CVE-2025-39987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. The driver will consume frame->len as-is with no further checks. This can result in a buffer overflow later on in hi3110_hw_tx() on this line: \tmemcpy(buf + HI3110_FIFO_EXT_DATA_OFF, \t frame->data, frame->len); Here, frame->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39988", "url": "https://ubuntu.com/security/CVE-2025-39988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the etas_es58x driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)); to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, es58x_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN(FD) frame. This can result in a buffer overflow. For example, using the es581.4 variant, the frame will be dispatched to es581_4_tx_can_msg(), go through the last check at the beginning of this function: \tif (can_is_canfd_skb(skb)) \t\treturn -EMSGSIZE; and reach this line: \tmemcpy(tx_can_msg->data, cf->data, cf->len); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU or CANFD_MTU (depending on the device capabilities). By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39932", "url": "https://ubuntu.com/security/CVE-2025-39932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work) In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again. I actually just hit the case using rxe: WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10 [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ... It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39940", "url": "https://ubuntu.com/security/CVE-2025-39940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stripe: fix a possible integer overflow There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39948", "url": "https://ubuntu.com/security/CVE-2025-39948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix Rx page leak on multi-buffer frames The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver. It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed. If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf(). Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc. The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page. Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with \"jumbo frames\" used by 9K MTU. To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts(). Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() on the last buffer of the frame indicating the end of packet. For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss. The xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame. Move the increment of the ntc local variable to ensure its updated *before* all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic requires the index of the element just after the current frame. Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rx_ring.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39950", "url": "https://ubuntu.com/security/CVE-2025-39950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR A NULL pointer dereference can occur in tcp_ao_finish_connect() during a connect() system call on a socket with a TCP-AO key added and TCP_REPAIR enabled. The function is called with skb being NULL and attempts to dereference it on tcp_hdr(skb)->seq without a prior skb validation. Fix this by checking if skb is NULL before dereferencing it. The commentary is taken from bpf_skops_established(), which is also called in the same flow. Unlike the function being patched, bpf_skops_established() validates the skb before dereferencing it. int main(void){ \tstruct sockaddr_in sockaddr; \tstruct tcp_ao_add tcp_ao; \tint sk; \tint one = 1; \tmemset(&sockaddr,'\\0',sizeof(sockaddr)); \tmemset(&tcp_ao,'\\0',sizeof(tcp_ao)); \tsk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); \tsockaddr.sin_family = AF_INET; \tmemcpy(tcp_ao.alg_name,\"cmac(aes128)\",12); \tmemcpy(tcp_ao.key,\"ABCDEFGHABCDEFGH\",16); \ttcp_ao.keylen = 16; \tmemcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); \tsetsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao, \tsizeof(tcp_ao)); \tsetsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one)); \tsockaddr.sin_family = AF_INET; \tsockaddr.sin_port = htobe16(123); \tinet_aton(\"127.0.0.1\", &sockaddr.sin_addr); \tconnect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr)); return 0; } $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall $ unshare -Urn BUG: kernel NULL pointer dereference, address: 00000000000000b6 PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39961", "url": "https://ubuntu.com/security/CVE-2025-39961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd/pgtbl: Fix possible race while increase page table level The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] \t\t\t\t\t Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.", "cve_priority": "medium", "cve_public_date": "2025-10-09 13:15:00 UTC" }, { "cve": "CVE-2025-22106", "url": "https://ubuntu.com/security/CVE-2025-22106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: unregister xdp rxq info in the reset path vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace. Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0 This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39934", "url": "https://ubuntu.com/security/CVE-2025-39934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39937", "url": "https://ubuntu.com/security/CVE-2025-39937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda (\"net: rfkill: gpio: get the name and type from device property\") rfkill_find_type() gets called with the possibly uninitialized \"const char *type_name;\" local variable. On x86 systems when rfkill-gpio binds to a \"BCM4752\" or \"LNV4752\" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no \"type\" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a \"BCM4752\"/\"LNV4752\" acpi_device 2. The stack happened to contain NULL where type_name is stored", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39938", "url": "https://ubuntu.com/security/CVE-2025-39938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and \"dai_data->graph[dai->id]\" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39942", "url": "https://ubuntu.com/security/CVE-2025-39942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size This is inspired by the check for data_offset + data_length.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39943", "url": "https://ubuntu.com/security/CVE-2025-39943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: validate data_offset and data_length field of smb_direct_data_transfer If data_offset and data_length of smb_direct_data_transfer struct are invalid, out of bounds issue could happen. This patch validate data_offset and data_length field in recv_done.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39944", "url": "https://ubuntu.com/security/CVE-2025-39944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp() The original code relies on cancel_delayed_work() in otx2_ptp_destroy(), which does not ensure that the delayed work item synctstamp_work has fully completed if it was already running. This leads to use-after-free scenarios where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp(). Furthermore, the synctstamp_work is cyclic, the likelihood of triggering the bug is nonnegligible. A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAF This is confirmed by a KASAN report: BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800aa09a18 by task bash/136 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled before the otx2_ptp is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced artificial delays within the otx2_sync_tstamp() function to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39945", "url": "https://ubuntu.com/security/CVE-2025-39945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cnic: Fix use-after-free bugs in cnic_delete_task The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39955", "url": "https://ubuntu.com/security/CVE-2025-39955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect(). syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk in the TCP_ESTABLISHED state. [0] syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destination As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes it to TCP_CLOSE and makes connect() possible, which restarts timers. Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the retransmit timer triggered the warning and the intended packet was not retransmitted. Let's call reqsk_fastopen_remove() in tcp_disconnect(). [0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) ", "cve_priority": "medium", "cve_public_date": "2025-10-09 10:15:00 UTC" }, { "cve": "CVE-2025-39947", "url": "https://ubuntu.com/security/CVE-2025-39947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Harden uplink netdev access against device unbind The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39949", "url": "https://ubuntu.com/security/CVE-2025-39949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qed: Don't collect too many protection override GRC elements In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer. This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESS where \"ADDRESS\" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure. The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783 or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663 Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39951", "url": "https://ubuntu.com/security/CVE-2025-39951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: virtio_uml: Fix use-after-free after put_device in probe When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39953", "url": "https://ubuntu.com/security/CVE-2025-39953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: split cgroup_destroy_wq into 3 workqueues A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction. Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio Call Trace: \tcgroup_lock_and_drain_offline+0x14c/0x1e8 \tcgroup_destroy_root+0x3c/0x2c0 \tcss_free_rwork_fn+0x248/0x338 \tprocess_one_work+0x16c/0x3b8 \tworker_thread+0x22c/0x3b0 \tkthread+0xec/0x100 \tret_from_fork+0x10/0x20 Root Cause: CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues \t\t\t\t// cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1) Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation This separation eliminates blocking in the CSS free path while waiting for offline operations to complete. [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39957", "url": "https://ubuntu.com/security/CVE-2025-39957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: increase scan_ies_len for S1G Currently the S1G capability element is not taken into account for the scan_ies_len, which leads to a buffer length validation failure in ieee80211_prep_hw_scan() and subsequent WARN in __ieee80211_start_scan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length.", "cve_priority": "medium", "cve_public_date": "2025-10-09 10:15:00 UTC" }, { "cve": "CVE-2025-39952", "url": "https://ubuntu.com/security/CVE-2025-39952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: avoid buffer overflow in WID string configuration Fix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537) This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39927", "url": "https://ubuntu.com/security/CVE-2025-39927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix race condition validating r_parent before applying state Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39923", "url": "https://ubuntu.com/security/CVE-2025-39923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2]. Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs. [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/ [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39869", "url": "https://ubuntu.com/security/CVE-2025-39869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map Fix a critical memory allocation bug in edma_setup_from_hw() where queue_priority_map was allocated with insufficient memory. The code declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8), but allocated memory using sizeof(s8) instead of the correct size. This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i; The bug manifested as kernel crashes with \"Oops - undefined instruction\" on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the memory corruption triggered kernel hardening features on Clang. Change the allocation to use sizeof(*queue_priority_map) which automatically gets the correct size for the 2D array structure.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39873", "url": "https://ubuntu.com/security/CVE-2025-39873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB can_put_echo_skb() takes ownership of the SKB and it may be freed during or after the call. However, xilinx_can xcan_write_frame() keeps using SKB after the call. Fix that by only calling can_put_echo_skb() after the code is done touching the SKB. The tx_lock is held for the entire xcan_write_frame() execution and also on the can_get_echo_skb() side so the order of operations does not matter. An earlier fix commit 3d3c817c3a40 (\"can: xilinx_can: Fix usage of skb memory\") did not move the can_put_echo_skb() call far enough. [mkl: add \"commit\" in front of sha1 in patch description] [mkl: fix indention]", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39911", "url": "https://ubuntu.com/security/CVE-2025-39911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration later than the first, the error path wants to free the IRQs requested so far. However, it uses the wrong dev_id argument for free_irq(), so it does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]--- Use the same dev_id for free_irq() as for request_irq(). I tested this with inserting code to fail intentionally.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39876", "url": "https://ubuntu.com/security/CVE-2025-39876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() The function of_phy_find_device may return NULL, so we need to take care before dereferencing phy_dev.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39881", "url": "https://ubuntu.com/security/CVE-2025-39881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernfs: Fix UAF in polling when open file is released A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism: BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1 psi_trigger_poll+0x3c/0x140 cgroup_pressure_poll+0x70/0xa0 cgroup_file_poll+0x8c/0x100 kernfs_fop_poll+0x11c/0x1c0 ep_item_poll.isra.0+0x188/0x2c0 Allocated by task 1: cgroup_file_open+0x88/0x388 kernfs_fop_open+0x73c/0xaf0 do_dentry_open+0x5fc/0x1200 vfs_open+0xa0/0x3f0 do_open+0x7e8/0xd08 path_openat+0x2fc/0x6b0 do_filp_open+0x174/0x368 Freed by task 8462: cgroup_file_release+0x130/0x1f8 kernfs_drain_open_files+0x17c/0x440 kernfs_drain+0x2dc/0x360 kernfs_show+0x1b8/0x288 cgroup_file_show+0x150/0x268 cgroup_pressure_write+0x1dc/0x340 cgroup_file_write+0x274/0x548 Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv epolling\t\t\tdisable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epoll_wait kernfs_fop_poll kernfs_get_active = true\techo 0 > cgroup.pressure ...\t\t\t\tcgroup_file_show \t\t\t\tkernfs_show \t\t\t\t// inactive kn \t\t\t\tkernfs_drain_open_files \t\t\t\tcft->release(of); \t\t\t\tkfree(ctx); \t\t\t\t... kernfs_get_active = false \t\t\t\techo 1 > cgroup.pressure \t\t\t\tkernfs_show \t\t\t\tkernfs_activate_one(kn); kernfs_fop_poll kernfs_get_active = true cgroup_file_poll psi_trigger_poll // UAF ... end: close(fd) To address this issue, introduce kernfs_get_active_of() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfs_get_active() with kernfs_get_active_of() to prevent further operations on released file descriptors.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39909", "url": "https://ubuntu.com/security/CVE-2025-39909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters() Patch series \"mm/damon: avoid divide-by-zero in DAMON module's parameters application\". DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors. Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters. This patch (of 2): During the calculation of 'hot_thres' and 'cold_thres', either 'sample_interval' or 'aggr_interval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggr_interval' is already required to be set no smaller than 'sample_interval' in damon_set_attrs(), only the case where 'sample_interval' is zero needs to be checked.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39916", "url": "https://ubuntu.com/security/CVE-2025-39916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters() When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39877", "url": "https://ubuntu.com/security/CVE-2025-39877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: fix use-after-free in state_show() state_show() reads kdamond->damon_ctx without holding damon_sysfs_lock. This allows a use-after-free race: CPU 0 CPU 1 ----- ----- state_show() damon_sysfs_turn_damon_on() ctx = kdamond->damon_ctx; mutex_lock(&damon_sysfs_lock); damon_destroy_ctx(kdamond->damon_ctx); kdamond->damon_ctx = NULL; mutex_unlock(&damon_sysfs_lock); damon_is_running(ctx); /* ctx is freed */ mutex_lock(&ctx->kdamond_lock); /* UAF */ (The race can also occur with damon_sysfs_kdamonds_rm_dirs() and damon_sysfs_kdamond_release(), which free or replace the context under damon_sysfs_lock.) Fix by taking damon_sysfs_lock before dereferencing the context, mirroring the locking used in pid_show(). The bug has existed since state_show() first accessed kdamond->damon_ctx.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39880", "url": "https://ubuntu.com/security/CVE-2025-39880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix invalid accesses to ceph_connection_v1_info There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use). On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets. con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39883", "url": "https://ubuntu.com/security/CVE-2025-39883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory When I did memory failure tests, below panic occurs: page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 Modules linked in: hwpoison_inject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- The root cause is that unpoison_memory() tries to check the PG_HWPoison flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps: 1.Offline memory block: echo offline > /sys/devices/system/memory/memory12/state 2.Get offlined memory pfn: page-types -b n -rlN 3.Write pfn to unpoison-pfn echo > /sys/kernel/debug/hwpoison/unpoison-pfn This scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail if pfn_to_online_page() == NULL to fix the bug.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39907", "url": "https://ubuntu.com/security/CVE-2025-39907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer Avoid below overlapping mappings by using a contiguous non-cacheable buffer. [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST, overlapping mappings aren't supported [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300 [ 4.097071] Modules linked in: [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1 [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT) [ 4.118824] Workqueue: events_unbound deferred_probe_work_func [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.131624] pc : add_dma_entry+0x23c/0x300 [ 4.135658] lr : add_dma_entry+0x23c/0x300 [ 4.139792] sp : ffff800009dbb490 [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000 [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8 [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20 [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006 [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58 [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000 [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40 [ 4.214185] Call trace: [ 4.216605] add_dma_entry+0x23c/0x300 [ 4.220338] debug_dma_map_sg+0x198/0x350 [ 4.224373] __dma_map_sg_attrs+0xa0/0x110 [ 4.228411] dma_map_sg_attrs+0x10/0x2c [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174 [ 4.242127] nand_read_oob+0x1d4/0x8e0 [ 4.245861] mtd_read_oob_std+0x58/0x84 [ 4.249596] mtd_read_oob+0x90/0x150 [ 4.253231] mtd_read+0x68/0xac", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39885", "url": "https://ubuntu.com/security/CVE-2025-39885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix recursive semaphore deadlock in fiemap call syzbot detected a OCFS2 hang due to a recursive semaphore on a FS_IOC_FIEMAP of the extent list on a specially crafted mmap file. context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline] RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline] RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline] RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26 Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89 f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41 RSP: 0018:ffffc9000403f950 EFLAGS: 00050256 RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038 RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060 RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42 R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098 R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f13850fd9 RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9 RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004 RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0 R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the extent list of this running mmap executable. The user supplied buffer to hold the fiemap information page faults calling ocfs2_page_mkwrite() which will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same semaphore. This recursive semaphore will hold filesystem locks and causes a hang of the fileystem. The ip_alloc_sem protects the inode extent list and size. Release the read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap() and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock on the last extent but simplifies the error path.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39913", "url": "https://ubuntu.com/security/CVE-2025-39913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork. syzbot reported the splat below. [0] The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytes At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes(). Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN. If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc(). Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork. The \"*copied\" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets \"*copied\" to 0. [0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 ", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39886", "url": "https://ubuntu.com/security/CVE-2025-39886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init() Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example: ... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ... The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event. We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc. As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there. Depends on mm patch \"memcg: skip cgroup_file_notify if spinning is not allowed\": https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/ v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39914", "url": "https://ubuntu.com/security/CVE-2025-39914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Silence warning when chunk allocation fails in trace_pid_write Syzkaller trigger a fault injection warning: WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning. The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-23143", "url": "https://ubuntu.com/security/CVE-2025-23143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod. When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1] Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule At step 3), the CIFS module calls sock_release() for the underlying TCP socket, and it returns quickly. However, the socket remains in FIN_WAIT_1 because incoming FIN packets are dropped. At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sock_release() and it returns, the TCP socket does not die immediately in order to close the connection gracefully. While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sk_lock using sock_lock_init_class_and_name(). Once an incoming packet is processed for the socket or a timer fires, sk->sk_lock is acquired. Then, LOCKDEP checks the lock context in check_wait_context(), where hlock_class() is called to retrieve the lock class. However, since the module has already been unloaded, hlock_class() logs a warning and returns NULL, triggering the null-ptr-deref. If LOCKDEP is enabled, we must ensure that a module calling sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue. Let's hold the module reference in sock_lock_init_class_and_name() and release it when the socket is freed in sk_prot_free(). Note that sock_lock_init() clears sk->sk_owner for svc_create_socket() that calls sock_lock_init_class_and_name() for a listening socket, which clones a socket by sk_clone_lock() without GFP_ZERO. [0]: CIFS_SERVER=\"10.0.0.137\" CIFS_PATH=\"//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST\" DEV=\"enp0s3\" CRED=\"/root/WindowsCredential.txt\" MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire (kernel/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-22124", "url": "https://ubuntu.com/security/CVE-2025-22124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb In clustermd, separate write-intent-bitmaps are used for each cluster node: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal to bitmap->storage.file_pages. Then bitmap_limit will be calculated to 0. md_super_write() will be called with 0 size. That means the first 4k sb area of node 1 will never be updated through filemap_write_page(). This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize. Here use (pg_index % bitmap->storage.file_pages) to make calculation of bitmap_limit correct.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-23133", "url": "https://ubuntu.com/security/CVE-2025-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: update channel list in reg notifier instead reg worker Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list(). But ath11k will immediately execute step 3 after reg_work is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0 Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set, cfg80211 will notify ath11k after step 2 is done. So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/ Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22113", "url": "https://ubuntu.com/security/CVE-2025-22113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid journaling sb update on error if journal is destroying Presently we always BUG_ON if trying to start a transaction on a journal marked with JBD2_UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for update_super_work to start a transaction after the journal is destroyed eg: (umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super \tflush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT) Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit. Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updates This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc86606) Also, we don't need a similar check in ext4_grp_locked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22125", "url": "https://ubuntu.com/security/CVE-2025-22125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: don't ignore IO flags If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced. Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks. Fix those problems by keep IO flags from master bio. Fises: f51d46d0e7cb (\"md: add support for REQ_NOWAIT\")", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39899", "url": "https://ubuntu.com/security/CVE-2025-39899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using kmap_local_page(), which requires unmapping in Last-In-First-Out order. The current code maps dst_pte first, then src_pte, but unmaps them in the same order (dst_pte, src_pte), violating the LIFO requirement. This causes the warning in kunmap_local_indexed(): WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c addr \\!= __fix_to_virt(FIX_KMAP_BEGIN + idx) Fix this by reversing the unmap order to respect LIFO ordering. This issue follows the same pattern as similar fixes: - commit eca6828403b8 (\"crypto: skcipher - fix mismatch between mapping and unmapping order\") - commit 8cf57c6df818 (\"nilfs2: eliminate staggered calls to kunmap in nilfs_rename\") Both of which addressed the same fundamental requirement that kmap_local operations must follow LIFO ordering.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39897", "url": "https://ubuntu.com/security/CVE-2025-39897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Add error handling for RX metadata pointer retrieval Add proper error checking for dmaengine_desc_get_metadata_ptr() which can return an error pointer and lead to potential crashes or undefined behaviour if the pointer retrieval fails. Properly handle the error by unmapping DMA buffer, freeing the skb and returning early to prevent further processing with invalid data.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39850", "url": "https://ubuntu.com/security/CVE-2025-39850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects When the \"proxy\" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the \"any\" remote (0.0.0.0 / ::). The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4]. Fix by checking that the remote destination exists before dereferencing it. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3 [3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77 [4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39851", "url": "https://ubuntu.com/security/CVE-2025-39851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD when refreshing an FDB entry with a nexthop object VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39852", "url": "https://ubuntu.com/security/CVE-2025-39852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm \"softirq\", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need to be called. They make sure the newsk will end up being correctly free'd. tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit label that takes care of things. So, this patch here makes sure tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar error-handling and thus fixes the leak for TCP-AO.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39901", "url": "https://ubuntu.com/security/CVE-2025-39901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: remove read access to debugfs files The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c (\"i40e: debugfs interface\"). Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here. On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be \": \". For 'netdev_ops', this will be \": \". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism. We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc. A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input. Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once. In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39854", "url": "https://ubuntu.com/security/CVE-2025-39854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the \"low latency\" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same \"ready\" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-38556", "url": "https://ubuntu.com/security/CVE-2025-38556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Harden s32ton() against conversion to 0 bits Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38502", "url": "https://ubuntu.com/security/CVE-2025-38502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix oob access in cgroup local storage Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf); For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access. To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.", "cve_priority": "medium", "cve_public_date": "2025-08-16 10:15:00 UTC" }, { "cve": "CVE-2025-39843", "url": "https://ubuntu.com/security/CVE-2025-39843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: slub: avoid wake up kswapd in set_track_prepare set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock. Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since ___slab_alloc() has preemption disabled, we mask out __GFP_DIRECT_RECLAIM from the flags there. The oops looks something like: BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c ___slab_alloc+0xccc __kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39920", "url": "https://ubuntu.com/security/CVE-2025-39920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pcmcia: Add error handling for add_interval() in do_validate_mem() In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next. This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39902", "url": "https://ubuntu.com/security/CVE-2025-39902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slub: avoid accessing metadata when pointer is invalid in object_err() object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object. One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process. In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39838", "url": "https://ubuntu.com/security/CVE-2025-39838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: prevent NULL pointer dereference in UTF16 conversion There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash. This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer. Found by Linux Verification Center (linuxtesting.org) with SVACE", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39839", "url": "https://ubuntu.com/security/CVE-2025-39839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix OOB read/write in network-coding decode batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write. Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39841", "url": "https://ubuntu.com/security/CVE-2025-39841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix buffer free/clear order in deferred receive path Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39891", "url": "https://ubuntu.com/security/CVE-2025-39891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Initialize the chan_stats array to zero The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey(). There are two potential issues here. What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak. Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc().", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39842", "url": "https://ubuntu.com/security/CVE-2025-39842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: prevent release journal inode after journal shutdown Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode(). ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> \t jbd2_journal_release_jbd_inode(osb->journal->j_journal, Adding osb->journal checks will prevent null-ptr-deref during the above execution path.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39895", "url": "https://ubuntu.com/security/CVE-2025-39895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: Fix sched_numa_find_nth_cpu() if mask offline sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer. The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline): [ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000 [ 1.423635] Mem abort info: [ 1.423889] ESR = 0x0000000096000006 [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.424715] SET = 0, FnV = 0 [ 1.424995] EA = 0, S1PTW = 0 [ 1.425279] FSC = 0x06: level 2 translation fault [ 1.425735] Data abort info: [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000 [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000 [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP [ 1.429525] Modules linked in: [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT) [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488 [ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488 [ 1.432543] sp : ffffffc084e1b960 [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0 [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378 [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7 [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372 [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860 [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000 [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68 [ 1.439332] Call trace: [ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P) [ 1.440016] smp_call_function_any+0xc8/0xd0 [ 1.440416] armv8_pmu_init+0x58/0x27c [ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c [ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8 [ 1.441603] armv8_pmu_device_probe+0x1c/0x28 [ 1.442007] platform_probe+0x5c/0xac [ 1.442347] really_probe+0xbc/0x298 [ 1.442683] __driver_probe_device+0x78/0x12c [ 1.443087] driver_probe_device+0xdc/0x160 [ 1.443475] __driver_attach+0x94/0x19c [ 1.443833] bus_for_each_dev+0x74/0xd4 [ 1.444190] driver_attach+0x24/0x30 [ 1.444525] bus_add_driver+0xe4/0x208 [ 1.444874] driver_register+0x60/0x128 [ 1.445233] __platform_driver_register+0x24/0x30 [ 1.445662] armv8_pmu_driver_init+0x28/0x4c [ 1.446059] do_one_initcall+0x44/0x25c [ 1.446416] kernel_init_freeable+0x1dc/0x3bc [ 1.446820] kernel_init+0x20/0x1d8 [ 1.447151] ret_from_fork+0x10/0x20 [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803) [ 1.448040] ---[ end trace 0000000000000000 ]--- [ 1.448483] note: swapper/0[1] exited with preempt_count 1 [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.449741] SMP: stopping secondary CPUs [ 1.450105] Kernel Offset: disabled [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b [ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39844", "url": "https://ubuntu.com/security/CVE-2025-39844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: move page table sync declarations to linux/pgtable.h During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 (\"x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes\")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39845", "url": "https://ubuntu.com/security/CVE-2025-39845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure page tables are properly synchronized when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...]", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39846", "url": "https://ubuntu.com/security/CVE-2025-39846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region() In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39847", "url": "https://ubuntu.com/security/CVE-2025-39847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix memory leak in pad_compress_skb If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop; drop: kfree_skb(skb); When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak. Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39848", "url": "https://ubuntu.com/security/CVE-2025-39848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: properly unshare skbs in ax25_kiss_rcv() Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d (\"net: introduce per netns packet chains\"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without a major crash. But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not. Many thanks to Bernard Pidoux for his help, diagnosis and tests. We had a similar issue years ago fixed with commit 7aaed57c5c28 (\"phonet: properly unshare skbs in phonet_rcv()\").", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39849", "url": "https://ubuntu.com/security/CVE-2025-39849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39853", "url": "https://ubuntu.com/security/CVE-2025-39853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39857", "url": "https://ubuntu.com/security/CVE-2025-39857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc] ... Call Trace: smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 If the software RoCE device is used, ibdev->dma_device is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39860", "url": "https://ubuntu.com/security/CVE-2025-39860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() syzbot reported the splat below without a repro. In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that. The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit. bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release(). Two threads could see the same socket during the list iteration in bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF Depending on the timing, the other thread could show up in the \"Freed by task\" part. Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release(). [0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39861", "url": "https://ubuntu.com/security/CVE-2025-39861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: vhci: Prevent use-after-free by removing debugfs files early Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed. Previously, debugfs files such as \"force_suspend\", \"force_wakeup\", and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors. Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39894", "url": "https://ubuntu.com/security/CVE-2025-39894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39864", "url": "https://ubuntu.com/security/CVE-2025-39864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix use-after-free in cmp_bss() Following bss_free() quirk introduced in commit 776b3580178f (\"cfg80211: track hidden SSID networks properly\"), adjust cfg80211_update_known_bss() to free the last beacon frame elements only if they're not shared via the corresponding 'hidden_beacon_bss' pointer.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39865", "url": "https://ubuntu.com/security/CVE-2025-39865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: fix NULL pointer dereference in tee_shm_put tee_shm_put have NULL pointer dereference: __optee_disable_shm_cache --> \tshm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> \t\ttee_shm_put(shm);//crash Add check in tee_shm_put to fix it. panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39866", "url": "https://ubuntu.com/security/CVE-2025-39866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix use-after-free in __mark_inode_dirty() An use-after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching. CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 ...... pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mark_inode_dirty+0x124/0x418 lr : __mark_inode_dirty+0x118/0x418 sp : ffffffc08c9dbbc0 ........ Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198 Root cause is: systemd-random-seed kworker ---------------------------------------------------------------------- ___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39811", "url": "https://ubuntu.com/security/CVE-2025-39811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Clear the scratch_pt pointer on error Avoid triggering a dereference of an error pointer on cleanup in xe_vm_free_scratch() by clearing any scratch_pt error pointer. (cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8)", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39815", "url": "https://ubuntu.com/security/CVE-2025-39815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: fix stack overrun when loading vlenb The userspace load can put up to 2048 bits into an xlen bit stack buffer. We want only xlen bits, so check the size beforehand.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39836", "url": "https://ubuntu.com/security/CVE-2025-39836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efi: stmm: Fix incorrect buffer allocation method The communication buffer allocated by setup_mm_hdr() is later on passed to tee_shm_register_kernel_buf(). The latter expects those buffers to be contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause various corruptions or BUGs, specifically since commit 9aec2fb0fd5e (\"slab: allocate frozen pages\"), though it was broken before as well. Fix this by using alloc_pages_exact() instead of kmalloc().", "cve_priority": "medium", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39805", "url": "https://ubuntu.com/security/CVE-2025-39805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix unregister_netdev call order in macb_remove() When removing a macb device, the driver calls phy_exit() before unregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ... The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus. Fix this by moving unregister_netdev() ahead of phy_exit() in macb_remove().", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39829", "url": "https://ubuntu.com/security/CVE-2025-39829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: trace/fgraph: Fix the warning caused by missing unregister notifier This warning was triggered during testing on v6.16: notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written. Fixed by adding unregister_pm_notifier in the exception path.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39835", "url": "https://ubuntu.com/security/CVE-2025-39835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: do not propagate ENODATA disk errors into xattr code ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found. However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as \"attribute not found\" when in fact it's an IO (disk) error. At worst, we may oops in xfs_attr_leaf_get() when we do: \terror = xfs_attr_leaf_hasname(args, &bp); \tif (error == -ENOATTR) { \t\txfs_trans_brelse(args->trans, bp); \t\treturn error; \t} because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfs_trans_brelse will then null-deref it. As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don't let unique errors like this leak up into higher xfs functions - many like this should be remapped to EIO. However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later. (Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.)", "cve_priority": "low", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39819", "url": "https://ubuntu.com/security/CVE-2025-39819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb: Fix inconsistent refcnt update A possible inconsistent update of refcount was identified in `smb2_compound_op`. Such inconsistent update could lead to possible resource leaks. Why it is a possible bug: 1. In the comment section of the function, it clearly states that the reference to `cfile` should be dropped after calling this function. 2. Every control flow path would check and drop the reference to `cfile`, except the patched one. 3. Existing callers would not handle refcount update of `cfile` if -ENOMEM is returned. To fix the bug, an extra goto label \"out\" is added, to make sure that the cleanup logic would always be respected. As the problem is caused by the allocation failure of `vars`, the cleanup logic between label \"finished\" and \"out\" can be safely ignored. According to the definition of function `is_replayable_error`, the error code of \"-ENOMEM\" is not recoverable. Therefore, the replay logic also gets ignored.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39808", "url": "https://ubuntu.com/security/CVE-2025-39808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version() in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58) add null check logic to ntrig_report_version() before calling hid_to_usb_dev()", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39806", "url": "https://ubuntu.com/security/CVE-2025-39806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it. Below is the KASAN splat after the out of bounds access happens: [ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 [...]", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39824", "url": "https://ubuntu.com/security/CVE-2025-39824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix UAF via HID_CLAIMED_INPUT validation After hid_hw_start() is called hidinput_connect() will eventually be called to set up the device with the input layer since the HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect() all input and output reports are processed and corresponding hid_inputs are allocated and configured via hidinput_configure_usages(). This process involves slot tagging report fields and configuring usages by setting relevant bits in the capability bitmaps. However it is possible that the capability bitmaps are not set at all leading to the subsequent hidinput_has_been_populated() check to fail leading to the freeing of the hid_input and the underlying input device. This becomes problematic because a malicious HID device like a ASUS ROG N-Key keyboard can trigger the above scenario via a specially crafted descriptor which then leads to a user-after-free when the name of the freed input device is written to later on after hid_hw_start(). Below, report 93 intentionally utilises the HID_UP_UNDEFINED Usage Page which is skipped during usage configuration, leading to the frees. 0x05, 0x0D, // Usage Page (Digitizer) 0x09, 0x05, // Usage (Touch Pad) 0xA1, 0x01, // Collection (Application) 0x85, 0x0D, // Report ID (13) 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) 0x09, 0xC5, // Usage (0xC5) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x04, // Report Count (4) 0xB1, 0x02, // Feature (Data,Var,Abs) 0x85, 0x5D, // Report ID (93) 0x06, 0x00, 0x00, // Usage Page (Undefined) 0x09, 0x01, // Usage (0x01) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x1B, // Report Count (27) 0x81, 0x02, // Input (Data,Var,Abs) 0xC0, // End Collection Below is the KASAN splat after triggering the UAF: [ 21.672709] ================================================================== [ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80 [ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54 [ 21.673700] [ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary) [ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 21.673700] Call Trace: [ 21.673700] [ 21.673700] dump_stack_lvl+0x5f/0x80 [ 21.673700] print_report+0xd1/0x660 [ 21.673700] kasan_report+0xe5/0x120 [ 21.673700] __asan_report_store8_noabort+0x1b/0x30 [ 21.673700] asus_probe+0xeeb/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 [...] [ 21.673700] [ 21.673700] Allocated by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_alloc_info+0x3b/0x50 [ 21.673700] __kasan_kmalloc+0x9c/0xa0 [ 21.673700] __kmalloc_cache_noprof+0x139/0x340 [ 21.673700] input_allocate_device+0x44/0x370 [ 21.673700] hidinput_connect+0xcb6/0x2630 [ 21.673700] hid_connect+0xf74/0x1d60 [ 21.673700] hid_hw_start+0x8c/0x110 [ 21.673700] asus_probe+0x5a3/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 [...] [ 21.673700] [ 21.673700] Freed by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_free_info+0x3f/0x60 [ 21.673700] __kasan_slab_free+0x3c/0x50 [ 21.673700] kfre ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39823", "url": "https://ubuntu.com/security/CVE-2025-39823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: use array_index_nospec with indices that come from guest min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39817", "url": "https://ubuntu.com/security/CVE-2025-39817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare Observed on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0 If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename: T1\t\t\tT2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list \t\t\tlookup_open \t\t\t d_alloc_parallel \t\t\t __d_lookup_rcu \t\t\t __d_lookup_rcu_op_compare \t\t\t hlist_bl_for_each_entry_rcu \t\t\t // invalid dentry can be retrieved \t\t\t ->d_compare \t\t\t efivarfs_d_compare \t\t\t // oob Fix it by checking 'guid' before cmp.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39812", "url": "https://ubuntu.com/security/CVE-2025-39812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: initialize more fields in sctp_v6_from_sk() syzbot found that sin6_scope_id was not properly initialized, leading to undefined behavior. Clear sin6_scope_id and sin6_flowinfo. BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39827", "url": "https://ubuntu.com/security/CVE-2025-39827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: include node references in rose_neigh refcount Current implementation maintains two separate reference counting mechanisms: the 'count' field in struct rose_neigh tracks references from rose_node structures, while the 'use' field (now refcount_t) tracks references from rose_sock. This patch merges these two reference counting systems using 'use' field for proper reference management. Specifically, this patch adds incrementing and decrementing of rose_neigh->use when rose_neigh->count is incremented or decremented. This patch also modifies rose_rt_free(), rose_rt_device_down() and rose_clear_route() to properly release references to rose_neigh objects before freeing a rose_node through rose_remove_node(). These changes ensure rose_neigh structures are properly freed only when all references, including those from rose_node structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39826", "url": "https://ubuntu.com/security/CVE-2025-39826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: convert 'use' field to refcount_t The 'use' field in struct rose_neigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a rose_neigh structure is freed while still being referenced by other code paths. For example, when rose_neigh->use becomes zero during an ioctl operation via rose_rt_ioctl(), the structure may be removed while its timer is still active, potentially causing use-after-free issues. This patch changes the type of 'use' from unsigned short to refcount_t and updates all code paths to use rose_neigh_hold() and rose_neigh_put() which operate reference counts atomically.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39832", "url": "https://ubuntu.com/security/CVE-2025-39832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix lockdep assertion on sync reset unload event Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning. Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39828", "url": "https://ubuntu.com/security/CVE-2025-39828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control(). syzbot reported the splat below. [0] When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message. The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc. The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer. struct atmtcp_control { \tstruct atmtcp_hdr hdr;\t/* must be first */ ... \tatm_kptr_t vcc;\t\t/* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t; The special message is processed in atmtcp_recv_control() called from atmtcp_c_send(). atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control. Let's add a new ->pre_send() hook to validate messages from sendmsg(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 Modules linked in:", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39697", "url": "https://ubuntu.com/security/CVE-2025-39697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39825", "url": "https://ubuntu.com/security/CVE-2025-39825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix race with concurrent opens in rename(2) Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file. Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39813", "url": "https://ubuntu.com/security/CVE-2025-39813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix potential warning in trace_printk_seq during ftrace_dump When calling ftrace_dump_one() concurrently with reading trace_pipe, a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race condition. The issue occurs because: CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger !trace_empty(&iter) trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipe trace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULL trace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size) In the context between trace_empty() and trace_find_next_entry_inc() during ftrace_dump, the ring buffer data was consumed by other readers. This caused trace_find_next_entry_inc to return NULL, failing to populate `iter.seq`. At this point, due to the prior trace_iterator_reset, both `iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal, the WARN_ON_ONCE condition is triggered. Move the trace_printk_seq() into the if block that checks to make sure the return value of trace_find_next_entry_inc() is non-NULL in ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before subsequent operations.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-37899", "url": "https://ubuntu.com/security/CVE-2025-37899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in session logoff The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-22037", "url": "https://ubuntu.com/security/CVE-2025-22037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference in alloc_preauth_hash() The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauth_info is not allocated. This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2141774, 2141778, 2141411, 1786013, 2141314, 2127764, 2137613, 2138120, 2136958, 2130240, 2067642, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664 ], "changes": [ { "cves": [], "log": [ "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.8.0-106.106", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 03:43:25 +0300" }, { "cves": [], "log": [ "", " * noble/linux: 6.8.0-104.104 -proposed tracker (LP: #2141774)", "", " * Change of ABI in 6.8.0 kernel breaks some OTT modules (LP: #2141778)", " - Revert \"net: tls: Cancel RX async resync request on rcd_delta overflow\"", " - Revert \"net: tls: Change async resync helpers argument\"", "" ], "package": "linux", "version": "6.8.0-104.104", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141774, 2141778 ], "author": "Edoardo Canepa ", "date": "Fri, 13 Feb 2026 19:36:26 +0100" }, { "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68198", "url": "https://ubuntu.com/security/CVE-2025-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crash: fix crashkernel resource shrink When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues: 1. Invalid crashkernel resource objects 2. Kernel crash if crashkernel shrinking is done twice For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as: cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel Instead, it should show 50MB: af000000-b21fffff : Crash kernel Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86): BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated. Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-38627", "url": "https://ubuntu.com/security/CVE-2025-38627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic The decompress_io_ctx may be released asynchronously after I/O completion. If this file is deleted immediately after read, and the kworker of processing post_read_wq has not been executed yet due to high workloads, It is possible that the inode(f2fs_inode_info) is evicted and freed before it is used f2fs_free_dic. The UAF case as below: Thread A Thread B - f2fs_decompress_end_io - f2fs_put_dic - queue_work add free_dic work to post_read_wq - do_unlink - iput - evict - call_rcu This file is deleted after read. Thread C kworker to process post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inode is freed by rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem read (dic->inode)->i_compress_algorithm This patch store compress_algorithm and sbi in dic to avoid inode UAF. In addition, the previous solution is deprecated in [1] may cause system hang. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68204", "url": "https://ubuntu.com/security/CVE-2025-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: arm: scmi: Fix genpd leak on provider registration failure If of_genpd_add_provider_onecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpd_debug_add(). Add proper error handling to unwind the initialized domains before returning from probe to ensure all resources are correctly released on failure. Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39981", "url": "https://ubuntu.com/security/CVE-2025-39981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible UAFs This attemps to fix possible UAFs caused by struct mgmt_pending being freed while still being processed like in the following trace, in order to fix mgmt_pending_valid is introduce and use to check if the mgmt_pending hasn't been removed from the pending list, on the complete callbacks it is used to check and in addtion remove the cmd from the list while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd is left on the list it can still be accessed and freed. BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55 CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 Allocated by task 12210: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x258/0x330 net/socket.c:1133 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 12221: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-22121", "url": "https://ubuntu.com/security/CVE-2025-22121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-23129", "url": "https://ubuntu.com/security/CVE-2025-23129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath11k_pci_alloc_msi(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This results in the below warning: WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c Call trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc The warning is due to not clearing the affinity hint before freeing the IRQs. So to fix this issue, clear the IRQ affinity hint before calling ath11k_pcic_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-40287", "url": "https://ubuntu.com/security/CVE-2025-40287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix improper check of dentry.stream.valid_size We found an infinite loop bug in the exFAT file system that can lead to a Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is malformed, the following system calls — SYS_openat, SYS_ftruncate, and SYS_pwrite64 — can cause the kernel to hang. Root cause analysis shows that the size validation code in exfat_find() does not check whether dentry.stream.valid_size is negative. As a result, the system calls mentioned above can succeed and eventually trigger the DoS issue. This patch adds a check for negative dentry.stream.valid_size to prevent this vulnerability.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40289", "url": "https://ubuntu.com/security/CVE-2025-40289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM Otherwise accessing them can cause a crash.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68201", "url": "https://ubuntu.com/security/CVE-2025-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: remove two invalid BUG_ON()s Those can be triggered trivially by userspace.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68180", "url": "https://ubuntu.com/security/CVE-2025-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref in debugfs odm_combine_segments When a connector is connected but inactive (e.g., disabled by desktop environments), pipe_ctx->stream_res.tg will be destroyed. Then, reading odm_combine_segments causes kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Fix this by checking pipe_ctx-> ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68322", "url": "https://ubuntu.com/security/CVE-2025-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Avoid crash due to unaligned access in unwinder Guenter Roeck reported this kernel crash on his emulated B160L machine: Starting network: udhcpc: started, v1.36.1 Backtrace: [<104320d4>] unwind_once+0x1c/0x5c [<10434a00>] walk_stackframe.isra.0+0x74/0xb8 [<10434a6c>] arch_stack_walk+0x28/0x38 [<104e5efc>] stack_trace_save+0x48/0x5c [<105d1bdc>] set_track_prepare+0x44/0x6c [<105d9c80>] ___slab_alloc+0xfc4/0x1024 [<105d9d38>] __slab_alloc.isra.0+0x58/0x90 [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0 [<105b8e54>] __anon_vma_prepare+0x60/0x280 [<105a823c>] __vmf_anon_prepare+0x68/0x94 [<105a8b34>] do_wp_page+0x8cc/0xf10 [<105aad88>] handle_mm_fault+0x6c0/0xf08 [<10425568>] do_page_fault+0x110/0x440 [<10427938>] handle_interruption+0x184/0x748 [<11178398>] schedule+0x4c/0x190 BUG: spinlock recursion on CPU#0, ifconfig/2420 lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0 While creating the stack trace, the unwinder uses the stack pointer to guess the previous frame to read the previous stack pointer from memory. The crash happens, because the unwinder tries to read from unaligned memory and as such triggers the unalignment trap handler which then leads to the spinlock recursion and finally to a deadlock. Fix it by checking the alignment before accessing the memory.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40305", "url": "https://ubuntu.com/security/CVE-2025-40305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq) if list_empty(&m->req_list). However, if the pipe is full, we need to read more data and this used to work prior to commit aaec5a95d59615 (\"pipe_read: don't wake up the writer if the pipe is still full\"). p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before the commit above) triggered the unnecessary wakeup. This wakeup calls p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux() will notice EPOLLIN and schedule_work(&m->rq). This no longer happens after the optimization above, change p9_fd_request() to use p9_poll_mux() instead of only checking for EPOLLOUT.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40307", "url": "https://ubuntu.com/security/CVE-2025-40307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: validate cluster allocation bits of the allocation bitmap syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68315", "url": "https://ubuntu.com/security/CVE-2025-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to detect potential corrupted nid in free_nid_list As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40339", "url": "https://ubuntu.com/security/CVE-2025-40339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix nullptr err of vm_handle_moved If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68311", "url": "https://ubuntu.com/security/CVE-2025-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: ip22zilog: Use platform device for probing After commit 84a9582fd203 (\"serial: core: Start managing serial controllers to enable runtime PM\") serial drivers need to provide a device in struct uart_port.dev otherwise an oops happens. To fix this issue for ip22zilog driver switch driver to a platform driver and setup the serial device in sgi-ip22 code.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68313", "url": "https://ubuntu.com/security/CVE-2025-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Add RDSEED fix for Zen5 There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 \"at a rate inconsistent with randomness while incorrectly signaling success (CF=1)\". Search the web for AMD-SB-7055 for more detail. Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40360", "url": "https://ubuntu.com/security/CVE-2025-40360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Do not dereference NULL pointer in plane reset The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68734", "url": "https://ubuntu.com/security/CVE-2025-68734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe() In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style. Compile tested only. Issue found using a prototype static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-40272", "url": "https://ubuntu.com/security/CVE-2025-40272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix use-after-free race in fault handler When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40077", "url": "https://ubuntu.com/security/CVE-2025-40077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid overflow while left shift operation Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-68245", "url": "https://ubuntu.com/security/CVE-2025-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit efa95b01da18 (\"netpoll: fix use after free\") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 (\"netpoll: fix use after free\") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40293", "url": "https://ubuntu.com/security/CVE-2025-40293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Don't overflow during division for dirty tracking If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow to 0 and this triggers divide by 0. In this case the index should just be 0, so reorganize things to divide by shift and avoid hitting any overflows.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40303", "url": "https://ubuntu.com/security/CVE-2025-40303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: ensure no dirty metadata is written back for an fs with errors [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68184", "url": "https://ubuntu.com/security/CVE-2025-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Disable AFBC support on Mediatek DRM driver Commit c410fa9b07c3 (\"drm/mediatek: Add AFBC support to Mediatek DRM driver\") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier. However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0. Kernel trace reports vblank timeouts constantly, and the render is garbled: ``` [CRTC:62:crtc-0] vblank wait timed out WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c [...] Hardware name: MediaTek Genio-700 EVK (DT) Workqueue: events_unbound commit_work pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c sp : ffff80008337bca0 x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000 x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70 x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ``` Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40268", "url": "https://ubuntu.com/security/CVE-2025-40268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: client: fix memory leak in smb3_fs_context_parse_param The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation. To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing. syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444 BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40269", "url": "https://ubuntu.com/security/CVE-2025-40269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential overflow of PCM transfer buffer The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0].", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40271", "url": "https://ubuntu.com/security/CVE-2025-40271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix uaf in proc_readdir_de() Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \\ NULL pde(tun2)", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68241", "url": "https://ubuntu.com/security/CVE-2025-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random. The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked. CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak] This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = N Ido Schimmel provided the simple test validation method [1]. The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed. [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \\ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \\ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \\ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-68246", "url": "https://ubuntu.com/security/CVE-2025-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: close accepted socket when per-IP limit rejects connection When the per-IP connection limit is exceeded in ksmbd_kthread_fn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS. Release client_sk before continuing. This bug was found with ZeroPath.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40273", "url": "https://ubuntu.com/security/CVE-2025-40273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: free copynotify stateid in nfs4_free_ol_stateid() Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period. However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd] This patch, instead, frees the associated copynotify stateid here. If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later. [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68208", "url": "https://ubuntu.com/security/CVE-2025-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: account for current allocated stack depth in widen_imprecise_scalars() The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st); Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loop Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68200", "url": "https://ubuntu.com/security/CVE-2025-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add bpf_prog_run_data_pointers() syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 (\"net/sched: Extend qdisc control block with tc control block\"), which added a wrong interaction with db58ba459202 (\"bpf: wire in data and data_end for cls_act_bpf\"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40275", "url": "https://ubuntu.com/security/CVE-2025-40275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd In snd_usb_create_streams(), for UAC version 3 devices, the Interface Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this call fails, a fallback routine attempts to obtain the IAD from the next interface and sets a BADD profile. However, snd_usb_mixer_controls_badd() assumes that the IAD retrieved from usb_ifnum_to_if() is always valid, without performing a NULL check. This can lead to a NULL pointer dereference when usb_ifnum_to_if() fails to find the interface descriptor. This patch adds a NULL pointer check after calling usb_ifnum_to_if() in snd_usb_mixer_controls_badd() to prevent the dereference. This issue was discovered by syzkaller, which triggered the bug by sending a crafted USB device descriptor.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40277", "url": "https://ubuntu.com/security/CVE-2025-40277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40278", "url": "https://ubuntu.com/security/CVE-2025-40278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak Fix a KMSAN kernel-infoleak detected by the syzbot . [net?] KMSAN: kernel-infoleak in __skb_datagram_iter In tcf_ife_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. This change silences the KMSAN report and prevents potential information leaks from the kernel memory. This fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures no infoleak.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40279", "url": "https://ubuntu.com/security/CVE-2025-40279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_connmark: initialize struct tc_ife to fix kernel leak In tcf_connmark_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40280", "url": "https://ubuntu.com/security/CVE-2025-40280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_mon_reinit_self(). syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0] The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL. tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work(). Let's hold RTNL in tipc_net_finalize_work(). [0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989 CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40281", "url": "https://ubuntu.com/security/CVE-2025-40281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto syzbot reported a possible shift-out-of-bounds [1] Blamed commit added rto_alpha_max and rto_beta_max set to 1000. It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta. In order to prevent user regression, perform the test at run time. Also add READ_ONCE() annotations as sysctl values can change under us. [1] UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40282", "url": "https://ubuntu.com/security/CVE-2025-40282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: 6lowpan: reset link-local header on ipv6 recv path Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW Add missing skb_reset_mac_header() for uncompressed ipv6 RX path. For the compressed one, it is done in lowpan_header_decompress(). Log: (BlueZ 6lowpan-tester Client Recv Raw - Success) ------ kernel BUG at net/core/skbuff.c:212! Call Trace: ... packet_rcv (net/packet/af_packet.c:2152) ... __local_bh_enable_ip (kernel/softirq.c:407) netif_rx (net/core/dev.c:5648) chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359) ------", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40283", "url": "https://ubuntu.com/security/CVE-2025-40283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF There is a KASAN: slab-use-after-free read in btusb_disconnect(). Calling \"usb_driver_release_interface(&btusb_driver, data->intf)\" will free the btusb data associated with the interface. The same data is then used later in the function, hence the UAF. Fix by moving the accesses to btusb data to before the data is free'd.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40284", "url": "https://ubuntu.com/security/CVE-2025-40284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in \"Mesh - Send cancel - 1\" test). Log: ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40285", "url": "https://ubuntu.com/security/CVE-2025-40285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix possible refcount leak in smb2_sess_setup() Reference count of ksmbd_session will leak when session need reconnect. Fix this by adding the missing ksmbd_user_session_put().", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40286", "url": "https://ubuntu.com/security/CVE-2025-40286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix possible memory leak in smb2_read() Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree().", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40288", "url": "https://ubuntu.com/security/CVE-2025-40288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices Previously, APU platforms (and other scenarios with uninitialized VRAM managers) triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL, but that `man->bdev` (the backing device pointer within the manager) remains uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to a kernel OOPS. 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference. 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL. 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report). This approach is more robust than APU-specific checks because it: - Works for all scenarios where the VRAM manager is uninitialized (not just APUs), - Aligns with TTM's design by using its native helper function, - Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check). v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68244", "url": "https://ubuntu.com/security/CVE-2025-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x16 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40292", "url": "https://ubuntu.com/security/CVE-2025-40292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix received length check in big packets Since commit 4959aebba8c0 (\"virtio-net: use mtu size as buffer length for big packets\"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40328", "url": "https://ubuntu.com/security/CVE-2025-40328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_close_cached_fid() find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free. Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40294", "url": "https://ubuntu.com/security/CVE-2025-40294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern() In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied. Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40329", "url": "https://ubuntu.com/security/CVE-2025-40329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()). CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0. Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock This will deadlock if f1 and f2 share the same spinlock. To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work(). [phasta: commit message nits]", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68320", "url": "https://ubuntu.com/security/CVE-2025-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix sleeping in atomic context The following warning was seen when we try to connect using ssh to the device. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear preempt_count: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE Tainted: [W]=WARN Hardware name: Generic DT based system Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8 It seems that we are using a mutex in a atomic context which is wrong. Change the mutex with a spinlock.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68192", "url": "https://ubuntu.com/security/CVE-2025-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks. Initialize the MAC header to prevent such crashes. This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface. Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40331", "url": "https://ubuntu.com/security/CVE-2025-40331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: Prevent TOCTOU out-of-bounds write For the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use).", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40301", "url": "https://ubuntu.com/security/CVE-2025-40301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: validate skb length for unknown CC opcode In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory. The fix is to check skb->len before using skb->data.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40358", "url": "https://ubuntu.com/security/CVE-2025-40358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: stacktrace: Disable KASAN checks for non-current tasks Unwinding the stack of a task other than current, KASAN would report \"BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460\" There is a same issue on x86 and has been resolved by the commit 84936118bdf3 (\"x86/unwind: Disable KASAN checks for non-current tasks\") The solution could be applied to RISC-V too. This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23 [pjw@kernel.org: clean up checkpatch issues]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40304", "url": "https://ubuntu.com/security/CVE-2025-40304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches. Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68183", "url": "https://ubuntu.com/security/CVE-2025-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with \"ima_appraise=fix evm=fix ima_policy=appraise_tcb\" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = \"/usr/sbin/test_binary\"; const char* hex_string = \"030204d33204490066306402304\"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror(\"Error opening file\"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, \"%2hhx\", &ima_attr_value[j]); } if (fsetxattr(fd, \"security.ima\", ima_attr_value, length/2, 0) == -1) { perror(\"Error setting extended attribute\"); close(fd); return 1; } const char* selinux_value= \"system_u:object_r:bin_t:s0\"; if (fsetxattr(fd, \"security.selinux\", selinux_value, strlen(selinux_value), 0) == -1) { perror(\"Error setting extended attribute\"); close(fd); return 1; } close(fd); return 0; }", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68173", "url": "https://ubuntu.com/security/CVE-2025-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix softlockup in ftrace_module_enable A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc (\"ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels\") and commit 42ea22e754ba (\"ftrace: Add cond_resched() to ftrace_graph_set_hash()\"). Fix it the same way by adding cond_resched() in ftrace_module_enable.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40306", "url": "https://ubuntu.com/security/CVE-2025-40306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau forwarded me a message from Disclosure with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr \"security.capability\" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for \"security.capability\" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40308", "url": "https://ubuntu.com/security/CVE-2025-40308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bcsp: receive data only if registered Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40309", "url": "https://ubuntu.com/security/CVE-2025-40309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on sco_conn_free BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline] BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline] BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352 CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci13 hci_cmd_sync_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40310", "url": "https://ubuntu.com/security/CVE-2025-40310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw There is race in amdgpu_amdkfd_device_fini_sw and interrupt. if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated. kernel panic log: BUG: kernel NULL pointer dereference, address: 0000000000000098 amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP PGD d78c68067 P4D d78c68067 kfd kfd: amdgpu: Allocated 3969056 bytes on gart PUD 1465b8067 PMD @ Oops: @002 [#1] SMP NOPTI kfd kfd: amdgpu: Total number of KFD nodes to be created: 4 CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40 Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc 89 c6 e8 07 38 5d RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018 0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098 ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020 0000000000000000 R11: 0000000000000000 R12: 0900000000000002 ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00 CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033 CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400 PKRU: 55555554 Call Trace: kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu] ? amdgpu_fence_process+0xa4/0x150 [amdgpu] kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace amdgpu_irq_dispatch+0x165/0x210 [amdgpu] amdgpu_ih_process+0x80/0x100 [amdgpu] amdgpu: Virtual CRAT table created for GPU amdgpu_irq_handler+0x1f/@x60 [amdgpu] __handle_irq_event_percpu+0x3d/0x170 amdgpu: Topology: Add dGPU node [0x74a2:0x1002] handle_irq_event+0x5a/@xcO handle_edge_irq+0x93/0x240 kfd kfd: amdgpu: KFD node 1 partition @ size 49148M asm_call_irq_on_stack+0xf/@x20 common_interrupt+0xb3/0x130 asm_common_interrupt+0x1le/0x40 5.10.134-010.a1i5000.a18.x86_64 #1", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40311", "url": "https://ubuntu.com/security/CVE-2025-40311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: support mapping cb with vmalloc-backed coherent memory When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction. Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68185", "url": "https://ubuntu.com/security/CVE-2025-68185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68176", "url": "https://ubuntu.com/security/CVE-2025-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: cadence: Check for the existence of cdns_pcie::ops before using it cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. [mani: reworded subject and description]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68168", "url": "https://ubuntu.com/security/CVE-2025-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix uninitialized waitqueue in transaction manager The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems. When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0. This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEnd Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40312", "url": "https://ubuntu.com/security/CVE-2025-40312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Verify inode mode when loading from disk The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 (\"isofs: Verify inode mode when loading from disk\") does.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40333", "url": "https://ubuntu.com/security/CVE-2025-40333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix infinite loop in __insert_extent_tree() When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68321", "url": "https://ubuntu.com/security/CVE-2025-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: page_pool: always add GFP_NOWARN for ATOMIC allocations Driver authors often forget to add GFP_NOWARN for page allocation from the datapath. This is annoying to users as OOMs are a fact of life, and we pretty much expect network Rx to hit page allocation failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations by default.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68191", "url": "https://ubuntu.com/security/CVE-2025-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: use netdev_warn() instead of netdev_WARN() netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug. udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug. Replace netdev_WARN() with netdev_warn() accordingly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40313", "url": "https://ubuntu.com/security/CVE-2025-40313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: pretend $Extend records as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40314", "url": "https://ubuntu.com/security/CVE-2025-40314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free. Fix: By separating the usb_del_gadget_udc() operation into distinct \"del\" and \"put\" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget(). A patch similar to bb9c74a5bd14(\"usb: dwc3: gadget: Free gadget structure only after freeing endpoints\").", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40337", "url": "https://ubuntu.com/security/CVE-2025-40337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Correctly handle Rx checksum offload errors The stmmac_rx function would previously set skb->ip_summed to CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype. However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause corrupt packets to be passed up the network stack as valid. This patch corrects the logic by checking the `csum_none` status flag, which is set when the hardware reports a checksum error. If this flag is set, skb->ip_summed is now correctly set to CHECKSUM_NONE, ensuring the kernel's network stack will perform its own validation and properly handle the corrupt packet.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68194", "url": "https://ubuntu.com/security/CVE-2025-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imon: make send_packet() more robust syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1]. First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls). Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away. but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed. Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb). Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf (\"[media] imon: don't wedge hardware after early callbacks\"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a (\"[media] imon: don't parse scancodes until intf configured\") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task). Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40363", "url": "https://ubuntu.com/security/CVE-2025-40363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix field-spanning memcpy warning in AH output Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field \"&top_iph->saddr\" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439 The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68178", "url": "https://ubuntu.com/security/CVE-2025-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix possible deadlock while configuring policy Following deadlock can be triggered easily by lockdep: WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180 but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30 -> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock); Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context. The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40341", "url": "https://ubuntu.com/security/CVE-2025-40341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Don't leak robust_list pointer on exec race sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged. A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec(). For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process. This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk. Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40342", "url": "https://ubuntu.com/security/CVE-2025-40342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: use lock accessing port_state and rport state nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40343", "url": "https://ubuntu.com/security/CVE-2025-40343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid scheduling association deletion twice When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68177", "url": "https://ubuntu.com/security/CVE-2025-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq/longhaul: handle NULL policy in longhaul_exit longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic. This patch adds a check using unlikely() and returns early if the policy is NULL. Bugzilla: #219962", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40315", "url": "https://ubuntu.com/security/CVE-2025-40315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix epfile null pointer access after ep enable. A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable(). The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock. Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68310", "url": "https://ubuntu.com/security/CVE-2025-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do. During error recovery testing a pair of tasks was reported to be hung: mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core] No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too: - task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock() - task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock. A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/ reporter fw_fatal while PCI error recovery is executed on the same physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with \"kernel answers: Permission denied\" - and we get a kernel log message of: mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5 because the config read of VSC_SEMAPHORE is rejected by the underlying hardware. Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68179", "url": "https://ubuntu.com/security/CVE-2025-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible crashes. The problem is that kernel page tables are modified without flushing corresponding TLB entries. Even if it looks like the empty flush_tlb_all() implementation on s390 is the problem, it is actually a different problem: on s390 it is not allowed to replace an active/valid page table entry with another valid page table entry without the detour over an invalid entry. A direct replacement may lead to random crashes and/or data corruption. In order to invalidate an entry special instructions have to be used (e.g. ipte or idte). Alternatively there are also special instructions available which allow to replace a valid entry with a different valid entry (e.g. crdte or cspg). Given that the HVO code currently does not provide the hooks to allow for an implementation which is compliant with the s390 architecture requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is basically a revert of the original patch which enabled it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40317", "url": "https://ubuntu.com/security/CVE-2025-40317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: slimbus: fix bus_context pointer in regmap init calls Commit 4e65bda8273c (\"ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()\") revealed the problem in the slimbus regmap. That commit breaks audio playback, for instance, on sdm845 Thundercomm Dragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19c The __devm_regmap_init_slimbus() started to be used instead of __regmap_init_slimbus() after the commit mentioned above and turns out the incorrect bus_context pointer (3rd argument) was used in __devm_regmap_init_slimbus(). It should be just \"slimbus\" (which is equal to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or the first user of devm_regmap_init_slimbus() but we should fix it till the point where __devm_regmap_init_slimbus() was introduced therefore two \"Fixes\" tags. While at this, also correct the same argument in __regmap_init_slimbus().", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40318", "url": "https://ubuntu.com/security/CVE-2025-40318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and \"UAF\". Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68312", "url": "https://ubuntu.com/security/CVE-2025-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Prevents free active kevent The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the \"free active object (kevent)\" error reported here. 2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed. The solution to this problem is to cancel the kevent before executing free_netdev().", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68172", "url": "https://ubuntu.com/security/CVE-2025-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aspeed - fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the manual clock cleanup in both aspeed_acry_probe()'s error path and aspeed_acry_remove().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40319", "url": "https://ubuntu.com/security/CVE-2025-40319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Sync pending IRQ work before freeing ring buffer Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work complete before freeing the buffer.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68171", "url": "https://ubuntu.com/security/CVE-2025-68171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Ensure XFD state on signal delivery Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40320", "url": "https://ubuntu.com/security/CVE-2025-40320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential cfid UAF in smb2_query_info_compound When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free. Reinitialize cfid to NULL under the replay label. Example trace (trimmed): refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40321", "url": "https://ubuntu.com/security/CVE-2025-40321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the \"actframe\" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for \"send_af_done\" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. [Cc stable]", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40322", "url": "https://ubuntu.com/security/CVE-2025-40322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_putcs* bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40211", "url": "https://ubuntu.com/security/CVE-2025-40211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: video: Fix use-after-free in acpi_video_switch_brightness() The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed. [ rjw: Changelog edit ]", "cve_priority": "medium", "cve_public_date": "2025-11-21 11:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40324", "url": "https://ubuntu.com/security/CVE-2025-40324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix crash in nfsd4_read_release() When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-37860", "url": "https://ubuntu.com/security/CVE-2025-37860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: fix NULL dereferences in ef100_process_design_param() Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point. Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err.", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21833", "url": "https://ubuntu.com/security/CVE-2025-21833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE There is a WARN_ON_ONCE to catch an unlikely situation when domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless happens we must avoid using a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-22105", "url": "https://ubuntu.com/security/CVE-2025-22105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: check xdp prog when set bond mode Following operations can trigger a warning[1]: ip netns add ns1 ip netns exec ns1 ip link add bond0 type bond mode balance-rr ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp ip netns exec ns1 ip link set bond0 type bond mode broadcast ip netns del ns1 When delete the namespace, dev_xdp_uninstall() is called to remove xdp program on bond dev, and bond_xdp_set() will check the bond mode. If bond mode is changed after attaching xdp program, the warning may occur. Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode with xdp program attached is not good. Add check for xdp program when set bond mode. [1] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930 Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ... RSP: 0018:ffffc90000063d80 EFLAGS: 00000282 RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48 RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8 R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000 FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0 Call Trace: ? __warn+0x83/0x130 ? unregister_netdevice_many_notify+0x8d9/0x930 ? report_bug+0x18e/0x1a0 ? handle_bug+0x54/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? unregister_netdevice_many_notify+0x8d9/0x930 ? bond_net_exit_batch_rtnl+0x5c/0x90 cleanup_net+0x237/0x3d0 process_one_work+0x163/0x390 worker_thread+0x293/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0xec/0x1e0 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-23130", "url": "https://ubuntu.com/security/CVE-2025-23130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid panic once fallocation fails for pinfile syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation. In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg()", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-40353", "url": "https://ubuntu.com/security/CVE-2025-40353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: mte: Do not warn if the page is already tagged in copy_highpage() The arm64 copy_highpage() assumes that the destination page is newly allocated and not MTE-tagged (PG_mte_tagged unset) and warns accordingly. However, following commit 060913999d7a (\"mm: migrate: support poisoned recover from migrate folio\"), folio_mc_copy() is called before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the copy will be done again to the same destination page. Since copy_highpage() already set the PG_mte_tagged flag, this second copy will warn. Replace the WARN_ON_ONCE(page already tagged) in the arm64 copy_highpage() with a comment.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-39678", "url": "https://ubuntu.com/security/CVE-2025-39678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL If metric table address is not allocated, accessing metrics_bin will result in a NULL pointer dereference, so add a check.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-40235", "url": "https://ubuntu.com/security/CVE-2025-40235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots() If fs_info->super_copy or fs_info->super_for_commit allocated failed in btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info(). Otherwise btrfs_check_leaked_roots() would access NULL pointer because fs_info->allocated_roots had not been initialised. syzkaller reported the following information: ------------[ cut here ]------------ BUG: unable to handle page fault for address: fffffffffffffbb0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...) RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline] RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline] RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline] RIP: 0010:refcount_read include/linux/refcount.h:170 [inline] RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230 [...] Call Trace: btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280 btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029 btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097 vfs_get_tree+0x98/0x320 fs/super.c:1759 do_new_mount+0x357/0x660 fs/namespace.c:3899 path_mount+0x716/0x19c0 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount fs/namespace.c:4427 [inline] __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f032eaffa8d [...]", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40238", "url": "https://ubuntu.com/security/CVE-2025-40238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix IPsec cleanup over MPV device When we do mlx5e_detach_netdev() we eventually disable blocking events notifier, among those events are IPsec MPV events from IB to core. So before disabling those blocking events, make sure to also unregister the devcom device and mark all this device operations as complete, in order to prevent the other device from using invalid netdev during future devcom events which could cause the trace below. BUG: kernel NULL pointer dereference, address: 0000000000000010 PGD 146427067 P4D 146427067 PUD 146488067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40 RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206 RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00 RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000 R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600 R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80 FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core] mlx5_devcom_send_event+0x8c/0x170 [mlx5_core] blocking_event+0x17b/0x230 [mlx5_core] notifier_call_chain+0x35/0xa0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core] mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib] mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib] ? idr_alloc_cyclic+0x50/0xb0 ? __kmalloc_cache_noprof+0x167/0x340 ? __kmalloc_noprof+0x1a7/0x430 __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe9/0x310 [mlx5_ib] ? kernfs_add_one+0x107/0x150 ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] auxiliary_bus_probe+0x3e/0x90 really_probe+0xc5/0x3a0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x62d/0x830 __auxiliary_device_add+0x3b/0xa0 ? auxiliary_device_init+0x41/0x90 add_adev+0xd1/0x150 [mlx5_core] mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core] esw_mode_change+0x6c/0xc0 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x180/0x2b0 ? devlink_get_from_attrs_lock+0x170/0x170 ? devlink_nl_eswitch_get_doit+0x290/0x290 ? devlink_nl_pre_doit_port_optional+0x50/0x50 ? genl_family_rcv_msg_dumpit+0xf0/0xf0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1fc/0x2d0 netlink_sendmsg+0x1e4/0x410 __sock_sendmsg+0x38/0x60 ? sockfd_lookup_light+0x12/0x60 __sys_sendto+0x105/0x160 ? __sys_recvmsg+0x4e/0x90 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f27bc91b13a Code: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40242", "url": "https://ubuntu.com/security/CVE-2025-40242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix unlikely race in gdlm_put_lock In gdlm_put_lock(), there is a small window of time in which the DFL_UNMOUNT flag has been set but the lockspace hasn't been released, yet. In that window, dlm may still call gdlm_ast() and gdlm_bast(). To prevent it from dereferencing freed glock objects, only free the glock if the lockspace has actually been released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40083", "url": "https://ubuntu.com/security/CVE-2025-40083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: Fix null-deref in agg_dequeue To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c. To avoid code duplication, the following changes are made: 1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function. 2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it. 3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40084", "url": "https://ubuntu.com/security/CVE-2025-40084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: transport_ipc: validate payload size before reading handle handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing. This is a minimal fix to guard the initial handle read.", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40220", "url": "https://ubuntu.com/security/CVE-2025-40220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: \"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40237", "url": "https://ubuntu.com/security/CVE-2025-40237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/notify: call exportfs_encode_fid with s_umount Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr. This issue was found by syzkaller. Race Condition Diagram: Thread 1 Thread 2 -------- -------- generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb) Which then leads to: [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none) [ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240 IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path. Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock. This form of fix was suggested by Amir in [1]. [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68249", "url": "https://ubuntu.com/security/CVE-2025-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: hdm_probe: Fix calling put_device() before device initialization The early error path in hdm_probe() can jump to err_free_mdev before &mdev->dev has been initialized with device_initialize(). Calling put_device(&mdev->dev) there triggers a device core WARN and ends up invoking kref_put(&kobj->kref, kobject_release) on an uninitialized kobject. In this path the private struct was only kmalloc'ed and the intended release is effectively kfree(mdev) anyway, so free it directly instead of calling put_device() on an uninitialized device. This removes the WARNING and fixes the pre-initialization error path.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40223", "url": "https://ubuntu.com/security/CVE-2025-40223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: Fix use-after-free in hdm_disconnect hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing. The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts). Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface(). This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40106", "url": "https://ubuntu.com/security/CVE-2025-40106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: fix divide-by-zero in comedi_buf_munge() The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands.", "cve_priority": "medium", "cve_public_date": "2025-10-31 10:15:00 UTC" }, { "cve": "CVE-2025-40226", "url": "https://ubuntu.com/security/CVE-2025-40226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Account for failed debug initialization When the SCMI debug subsystem fails to initialize, the related debug root will be missing, and the underlying descriptor will be NULL. Handle this fault condition in the SCMI debug helpers that maintain metrics counters.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40231", "url": "https://ubuntu.com/security/CVE-2025-40231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix lock inversion in vsock_assign_transport() Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called. The issue was introduced by commit 687aa0c5581b (\"vsock: Fix transport_* TOCTOU\") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created. Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40233", "url": "https://ubuntu.com/security/CVE-2025-40233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: clear extent cache after moving/defragmenting extents The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters(). The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40346", "url": "https://ubuntu.com/security/CVE-2025-40346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arch_topology: Fix incorrect error check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: \"The error code within @ptr if it is an error pointer; 0 otherwise.\" This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40240", "url": "https://ubuntu.com/security/CVE-2025-40240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid NULL dereference when chunk data buffer is missing chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only. chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40350", "url": "https://ubuntu.com/security/CVE-2025-40350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run. Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it. To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40347", "url": "https://ubuntu.com/security/CVE-2025-40347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: fix the deadlock of enetc_mdio_lock After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock: enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdio After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang. Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40243", "url": "https://ubuntu.com/security/CVE-2025-40243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits() The syzbot reported issue in hfs_find_set_zero_bits(): ===================================================== BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408 hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353 __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151 block_write_begin fs/buffer.c:2262 [inline] cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 cont_expand_zero fs/buffer.c:2528 [inline] cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654 notify_change+0x1993/0x1aa0 fs/attr.c:552 do_truncate+0x28f/0x310 fs/open.c:68 do_ftruncate+0x698/0x730 fs/open.c:195 do_sys_ftruncate fs/open.c:210 [inline] __do_sys_ftruncate fs/open.c:215 [inline] __se_sys_ftruncate fs/open.c:213 [inline] __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213 x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354 kmalloc_noprof include/linux/slab.h:905 [inline] hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337 get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681 get_tree_bdev+0x38/0x50 fs/super.c:1704 hfs_get_tree+0x35/0x40 fs/hfs/super.c:388 vfs_get_tree+0xb0/0x5c0 fs/super.c:1804 do_new_mount+0x738/0x1610 fs/namespace.c:3902 path_mount+0x6db/0x1e90 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427 x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 ===================================================== The HFS_SB(sb)->bitmap buffer is allocated in hfs_mdb_get(): HFS_SB(sb)->bitmap = kmalloc(8192, GFP_KERNEL); Finally, it can trigger the reported issue because kmalloc() doesn't clear the allocated memory. If allocated memory contains only zeros, then everything will work pretty fine. But if the allocated memory contains the \"garbage\", then it can affect the bitmap operations and it triggers the reported issue. This patch simply exchanges the kmalloc() on kzalloc() with the goal to guarantee the correctness of bitmap operations. Because, newly created allocation bitmap should have all available blocks free. Potentially, initialization bitmap's read operation could not fill the whole allocated memory and \"garbage\" in the not initialized memory will be the reason of volume coruptions and file system driver bugs.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40351", "url": "https://ubuntu.com/security/CVE-2025-40351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat() The syzbot reported issue in hfsplus_delete_cat(): [ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] __se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40349", "url": "https://ubuntu.com/security/CVE-2025-40349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: validate record offset in hfsplus_bmap_alloc hfsplus_bmap_alloc can trigger a crash if a record offset or length is larger than node_size [ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0 [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183 [ 15.265949] [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary) [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 15.266167] Call Trace: [ 15.266168] [ 15.266169] dump_stack_lvl+0x53/0x70 [ 15.266173] print_report+0xd0/0x660 [ 15.266181] kasan_report+0xce/0x100 [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0 [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0 [ 15.266217] hfsplus_brec_insert+0x870/0xb00 [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570 [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910 [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200 [ 15.266233] hfsplus_file_extend+0x5a7/0x1000 [ 15.266237] hfsplus_get_block+0x12b/0x8c0 [ 15.266238] __block_write_begin_int+0x36b/0x12c0 [ 15.266251] block_write_begin+0x77/0x110 [ 15.266252] cont_write_begin+0x428/0x720 [ 15.266259] hfsplus_write_begin+0x51/0x100 [ 15.266262] cont_write_begin+0x272/0x720 [ 15.266270] hfsplus_write_begin+0x51/0x100 [ 15.266274] generic_perform_write+0x321/0x750 [ 15.266285] generic_file_write_iter+0xc3/0x310 [ 15.266289] __kernel_write_iter+0x2fd/0x800 [ 15.266296] dump_user_range+0x2ea/0x910 [ 15.266301] elf_core_dump+0x2a94/0x2ed0 [ 15.266320] vfs_coredump+0x1d85/0x45e0 [ 15.266349] get_signal+0x12e3/0x1990 [ 15.266357] arch_do_signal_or_restart+0x89/0x580 [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110 [ 15.266364] asm_exc_page_fault+0x26/0x30 [ 15.266366] RIP: 0033:0x41bd35 [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283 [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000 [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100 [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000 [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000 [ 15.266376] When calling hfsplus_bmap_alloc to allocate a free node, this function first retrieves the bitmap from header node and map node using node->page together with the offset and length from hfs_brec_lenoff ``` len = hfs_brec_lenoff(node, 2, &off16); off = off16; off += node->page_offset; pagep = node->page + (off >> PAGE_SHIFT); data = kmap_local_page(*pagep); ``` However, if the retrieved offset or length is invalid(i.e. exceeds node_size), the code may end up accessing pages outside the allocated range for this node. This patch adds proper validation of both offset and length before use, preventing out-of-bounds page access. Move is_bnode_offset_valid and check_and_correct_requested_length to hfsplus_fs.h, as they may be required by other functions.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40244", "url": "https://ubuntu.com/security/CVE-2025-40244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() The syzbot reported issue in __hfsplus_ext_cache_extent(): [ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0 [ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.196959][ T9350] cont_write_begin+0x1000/0x1950 [ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.199393][ T9350] vfs_write+0xb0f/0x14e0 [ 70.199771][ T9350] ksys_write+0x23e/0x490 [ 70.200149][ T9350] __x64_sys_write+0x97/0xf0 [ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.202054][ T9350] [ 70.202279][ T9350] Uninit was created at: [ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80 [ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0 [ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0 [ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.205074][ T9350] cont_write_begin+0x1000/0x1950 [ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.207552][ T9350] vfs_write+0xb0f/0x14e0 [ 70.207961][ T9350] ksys_write+0x23e/0x490 [ 70.208375][ T9350] __x64_sys_write+0x97/0xf0 [ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.210230][ T9350] [ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5 [ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.212115][ T9350] ===================================================== [ 70.212734][ T9350] Disabling lock debugging due to kernel taint [ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ... [ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5 [ 70.214679][ T9350] Tainted: [B]=BAD_PAGE [ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.215999][ T9350] Call Trace: [ 70.216309][ T9350] [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0 [ 70.217025][ T9350] dump_stack+0x1e/0x30 [ 70.217421][ T9350] panic+0x502/0xca0 [ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ... kernel :[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 set ... [ 70.221254][ T9350] ? __msan_warning+0x96/0x120 [ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0 [ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0 [ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0 [ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950 [ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130 [ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060 [ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460 [ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0 [ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0 [ 70.228997][ T9350] ? ksys_write+0x23e/0x490 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40245", "url": "https://ubuntu.com/security/CVE-2025-40245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nios2: ensure that memblock.current_limit is set when setting pfn limits On nios2, with CONFIG_FLATMEM set, the kernel relies on memblock_get_current_limit() to determine the limits of mem_map, in particular for max_low_pfn. Unfortunately, memblock.current_limit is only default initialized to MEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading to situations where max_low_pfn can erroneously exceed the value of max_pfn and, thus, the valid range of available DRAM. This can in turn cause kernel-level paging failures, e.g.: [ 76.900000] Unable to handle kernel paging request at virtual address 20303000 [ 76.900000] ea = c0080890, ra = c000462c, cause = 14 [ 76.900000] Kernel panic - not syncing: Oops [ 76.900000] ---[ end Kernel panic - not syncing: Oops ]--- This patch fixes this by pre-calculating memblock.current_limit based on the upper limits of the available memory ranges via adjust_lowmem_bounds, a simplified version of the equivalent implementation within the arm architecture.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40105", "url": "https://ubuntu.com/security/CVE-2025-40105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: Don't leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (\"VFS: don't keep disconnected dentries on d_anon\") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are \"leaked\". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous \"Busy inodes after unmount\" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40092", "url": "https://ubuntu.com/security/CVE-2025-40092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Refactor bind path to use __free() After an bind/unbind cycle, the ncm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40101", "url": "https://ubuntu.com/security/CVE-2025-40101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST At the end of btrfs_load_block_group_zone_info() the first thing we do is to ensure that if the mapping type is not a SINGLE one and there is no RAID stripe tree, then we return early with an error. Doing that, though, prevents the code from running the last calls from this function which are about freeing memory allocated during its run. Hence, in this case, instead of returning early, we set the ret value and fall through the rest of the cleanup code.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40166", "url": "https://ubuntu.com/security/CVE-2025-40166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Check GuC running state before deregistering exec queue In normal operation, a registered exec queue is disabled and deregistered through the GuC, and freed only after the GuC confirms completion. However, if the driver is forced to unbind while the exec queue is still running, the user may call exec_destroy() after the GuC has already been stopped and CT communication disabled. In this case, the driver cannot receive a response from the GuC, preventing proper cleanup of exec queue resources. Fix this by directly releasing the resources when GuC is not running. Here is the failure dmesg log: \" [ 468.089581] ---[ end trace 0000000000000000 ]--- [ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535) [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535 [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1 [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1) [ 468.092716] ------------[ cut here ]------------ [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe] \" v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled(). As CT may go down and come back during VF migration. (cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40104", "url": "https://ubuntu.com/security/CVE-2025-40104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ixgbevf: fix mailbox API compatibility by negotiating supported features There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API. This convention has been broken since introducing API 1.4. Commit 0062e7cc955e (\"ixgbevf: add VF IPsec offload code\") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself. Commit 339f28964147 (\"ixgbevf: Add support for new mailbox communication between PF and VF\") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes. The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 (\"ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5\"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX. To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox. New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op. Features negotiation mechanism gives possibility to be extended with new features when needed in the future.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40087", "url": "https://ubuntu.com/security/CVE-2025-40087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Define a proc_layoutcommit for the FlexFiles layout type Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40196", "url": "https://ubuntu.com/security/CVE-2025-40196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to \"events_unbound\" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance \"writeback\" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40088", "url": "https://ubuntu.com/security/CVE-2025-40088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp() The hfsplus_strcasecmp() logic can trigger the issue: [ 117.317703][ T9855] ================================================================== [ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490 [ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855 [ 117.319577][ T9855] [ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full) [ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 117.319783][ T9855] Call Trace: [ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0 [ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10 [ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0 [ 117.319816][ T9855] ? lock_release+0x4b/0x3e0 [ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40 [ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319842][ T9855] print_report+0x17e/0x7e0 [ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319862][ T9855] ? __phys_addr+0xd3/0x180 [ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319876][ T9855] kasan_report+0x147/0x180 [ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490 [ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10 [ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0 [ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470 [ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10 [ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10 [ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510 [ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10 [ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510 [ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0 [ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120 [ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890 [ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10 [ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0 [ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80 [ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10 [ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100 [ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150 [ 117.320034][ T9855] __lookup_slow+0x297/0x3d0 [ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10 [ 117.320045][ T9855] ? down_read+0x1ad/0x2e0 [ 117.320055][ T9855] lookup_slow+0x53/0x70 [ 117.320065][ T9855] walk_component+0x2f0/0x430 [ 117.320073][ T9855] path_lookupat+0x169/0x440 [ 117.320081][ T9855] filename_lookup+0x212/0x590 [ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10 [ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290 [ 117.320105][ T9855] ? getname_flags+0x1e5/0x540 [ 117.320112][ T9855] user_path_at+0x3a/0x60 [ 117.320117][ T9855] __x64_sys_umount+0xee/0x160 [ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10 [ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0 [ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0 [ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0 [ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07 [ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08 [ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40085", "url": "https://ubuntu.com/security/CVE-2025-40085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card In try_to_register_card(), the return value of usb_ifnum_to_if() is passed directly to usb_interface_claimed() without a NULL check, which will lead to a NULL pointer dereference when creating an invalid USB audio device. Fix this by adding a check to ensure the interface pointer is valid before passing it to usb_interface_claimed().", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40172", "url": "https://ubuntu.com/security/CVE-2025-40172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() Currently, if find_and_map_user_pages() takes a DMA xfer request from the user with a length field set to 0, or in a rare case, the host receives QAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size is equal to the requested transaction size, the function will return 0 before allocating an sgt or setting the fields of the dma_xfer struct. In that case, encode_addr_size_pairs() will try to access the sgt which will lead to a general protection fault. Return an EINVAL in case the user provides a zero-sized ALP, or the device requests continuation after all of the bytes have been transferred.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40176", "url": "https://ubuntu.com/security/CVE-2025-40176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: wait for pending async decryptions if tls_strp_msg_hold fails Async decryption calls tls_strp_msg_hold to create a clone of the input skb to hold references to the memory it uses. If we fail to allocate that clone, proceeding with async decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, wait for all pending decryption requests.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40173", "url": "https://ubuntu.com/security/CVE-2025-40173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ip6_tunnel: Prevent perpetual tunnel growth Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd (\"net: ip_tunnel: prevent perpetual headroom growth\"), ipv6 tunnel yet increases the headroom without any ceiling. Reflect ipv4 tunnel headroom adjustment limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-specific patch and a reproducer.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40095", "url": "https://ubuntu.com/security/CVE-2025-40095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Refactor bind path to use __free() After an bind/unbind cycle, the rndis->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40094", "url": "https://ubuntu.com/security/CVE-2025-40094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_acm: Refactor bind path to use __free() After an bind/unbind cycle, the acm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec gs_free_req+0x30/0x44 acm_bind+0x1b8/0x1f4 usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40093", "url": "https://ubuntu.com/security/CVE-2025-40093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ecm: Refactor bind path to use __free() After an bind/unbind cycle, the ecm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40165", "url": "https://ubuntu.com/security/CVE-2025-40165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: m2m: Fix streaming cleanup on release If streamon/streamoff calls are imbalanced, such as when exiting an application with Ctrl+C when streaming, the m2m usage_count will never reach zero and the ISI channel won't be freed. Besides from that, if the input line width is more than 2K, it will trigger a WARN_ON(): [ 59.222120] ------------[ cut here ]------------ [ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654 [ 59.238569] Modules linked in: ap1302 [ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT [ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT) [ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120 [ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120 [ 59.275047] sp : ffff8000848c3b40 [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00 [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001 [ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780 [ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000 [ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c [ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30 [ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420 [ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000 [ 59.349590] Call trace: [ 59.352025] mxc_isi_channel_chain+0xa4/0x120 (P) [ 59.356722] mxc_isi_m2m_streamon+0x160/0x20c [ 59.361072] v4l_streamon+0x24/0x30 [ 59.364556] __video_do_ioctl+0x40c/0x4a0 [ 59.368560] video_usercopy+0x2bc/0x690 [ 59.372382] video_ioctl2+0x18/0x24 [ 59.375857] v4l2_ioctl+0x40/0x60 [ 59.379168] __arm64_sys_ioctl+0xac/0x104 [ 59.383172] invoke_syscall+0x48/0x104 [ 59.386916] el0_svc_common.constprop.0+0xc0/0xe0 [ 59.391613] do_el0_svc+0x1c/0x28 [ 59.394915] el0_svc+0x34/0xf4 [ 59.397966] el0t_64_sync_handler+0xa0/0xe4 [ 59.402143] el0t_64_sync+0x198/0x19c [ 59.405801] ---[ end trace 0000000000000000 ]--- Address this issue by moving the streaming preparation and cleanup to the vb2 .prepare_streaming() and .unprepare_streaming() operations. This also simplifies the driver by allowing direct usage of the v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40096", "url": "https://ubuntu.com/security/CVE-2025-40096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free. Interestingly this bug appears to have been present ever since commit ebd5f74255b9 (\"drm/sched: Add dependency tracking\"), since the code back then looked like this: drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]); Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it. The bug was then only noticed and fixed after commit 9c2ba265352a (\"drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2\") landed, with its fixup of commit 4eaf02d6076c (\"drm/scheduler: fix drm_sched_job_add_implicit_dependencies\"). At that point it was a slightly different flavour of a double free, which commit 963d0b356935 (\"drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder\") noticed and attempted to fix. But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case. As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain. While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.", "cve_priority": "low", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40099", "url": "https://ubuntu.com/security/CVE-2025-40099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: parse_dfs_referrals: prevent oob on malformed input Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS - reply smaller than sizeof(struct get_dfs_referral_rsp) - reply with number of referrals smaller than NumberOfReferrals in the header Processing of such replies will cause oob. Return -EINVAL error on such replies to prevent oob-s.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40100", "url": "https://ubuntu.com/security/CVE-2025-40100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40167", "url": "https://ubuntu.com/security/CVE-2025-40167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: detect invalid INLINE_DATA + EXTENTS flag combination syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal. The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 This is an invalid combination since an inode should have either: - INLINE_DATA: data stored directly in the inode - EXTENTS: data stored in extent-mapped blocks Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40198", "url": "https://ubuntu.com/security/CVE-2025-40198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40159", "url": "https://ubuntu.com/security/CVE-2025-40159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Harden userspace-supplied xdp_desc validation Turned out certain clearly invalid values passed in xdp_desc from userspace can pass xp_{,un}aligned_validate_desc() and then lead to UBs or just invalid frames to be queued for xmit. desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len can cause positive integer overflow and wraparound, the same way low enough desc->addr with a non-zero pool->tx_metadata_len can cause negative integer overflow. Both scenarios can then pass the validation successfully. This doesn't happen with valid XSk applications, but can be used to perform attacks. Always promote desc->len to ``u64`` first to exclude positive overflows of it. Use explicit check_{add,sub}_overflow() when validating desc->addr (which is ``u64`` already). bloat-o-meter reports a little growth of the code size: add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44) Function old new delta xskq_cons_peek_desc 299 330 +31 xsk_tx_peek_release_desc_batch 973 1002 +29 xsk_generic_xmit 3148 3132 -16 but hopefully this doesn't hurt the performance much.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40221", "url": "https://ubuntu.com/security/CVE-2025-40221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: mg4b: fix uninitialized iio scan data Fix potential leak of uninitialized stack data to userspace by ensuring that the `scan` structure is zeroed before use.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40180", "url": "https://ubuntu.com/security/CVE-2025-40180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40178", "url": "https://ubuntu.com/security/CVE-2025-40178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pid: Add a judgment for ns null in pid_nr_ns __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: \tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058 \tMem abort info: \tESR = 0x0000000096000007 \tEC = 0x25: DABT (current EL), IL = 32 bits \tSET = 0, FnV = 0 \tEA = 0, S1PTW = 0 \tFSC = 0x07: level 3 translation fault \tData abort info: \tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 \tCM = 0, WnR = 0, TnD = 0, TagAccess = 0 \tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 \t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 \tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) \tpc : __task_pid_nr_ns+0x74/0xd0 \tlr : __task_pid_nr_ns+0x24/0xd0 \tsp : ffffffc08001bd10 \tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 \tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 \tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 \tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 \tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc \tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 \tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 \tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 \tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc \tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 \tCall trace: \t__task_pid_nr_ns+0x74/0xd0 \t... \t__handle_irq_event_percpu+0xd4/0x284 \thandle_irq_event+0x48/0xb0 \thandle_fasteoi_irq+0x160/0x2d8 \tgeneric_handle_domain_irq+0x44/0x60 \tgic_handle_irq+0x4c/0x114 \tcall_on_irq_stack+0x3c/0x74 \tdo_interrupt_handler+0x4c/0x84 \tel1_interrupt+0x34/0x58 \tel1h_64_irq_handler+0x18/0x24 \tel1h_64_irq+0x68/0x6c \taccount_kernel_stack+0x60/0x144 \texit_task_stack_account+0x1c/0x80 \tdo_exit+0x7e4/0xaf8 \t... \tget_signal+0x7bc/0x8d8 \tdo_notify_resume+0x128/0x828 \tel0_svc+0x6c/0x70 \tel0t_64_sync_handler+0x68/0xbc \tel0t_64_sync+0x1a8/0x1ac \tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) \t---[ end trace 0000000000000000 ]--- \tKernel panic - not syncing: Oops: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40202", "url": "https://ubuntu.com/security/CVE-2025-40202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Rework user message limit handling The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free. Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine. It's a lot cleaner and safer.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40032", "url": "https://ubuntu.com/security/CVE-2025-40032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 [mani: trimmed the stack trace]", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40038", "url": "https://ubuntu.com/security/CVE-2025-40038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b Note, this is essentially a reapply of commit 5c30e8101e8d (\"KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid\"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons).", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40042", "url": "https://ubuntu.com/security/CVE-2025-40042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race condition in kprobe initialization causing NULL pointer dereference There is a critical race condition in kprobe initialization that can lead to NULL pointer dereference and kernel crash. [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000 ... [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO) [1135630.269239] pc : kprobe_perf_func+0x30/0x260 [1135630.277643] lr : kprobe_dispatcher+0x44/0x60 [1135630.286041] sp : ffffaeff4977fa40 [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400 [1135630.302837] x27: 0000000000000000 x26: 0000000000000000 [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528 [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50 [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50 [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000 [1135630.349985] x17: 0000000000000000 x16: 0000000000000000 [1135630.359285] x15: 0000000000000000 x14: 0000000000000000 [1135630.368445] x13: 0000000000000000 x12: 0000000000000000 [1135630.377473] x11: 0000000000000000 x10: 0000000000000000 [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000 [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000 [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000 [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006 [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000 [1135630.429410] Call trace: [1135630.434828] kprobe_perf_func+0x30/0x260 [1135630.441661] kprobe_dispatcher+0x44/0x60 [1135630.448396] aggr_pre_handler+0x70/0xc8 [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0 [1135630.462435] brk_handler+0xbc/0xd8 [1135630.468437] do_debug_exception+0x84/0x138 [1135630.475074] el1_dbg+0x18/0x8c [1135630.480582] security_file_permission+0x0/0xd0 [1135630.487426] vfs_write+0x70/0x1c0 [1135630.493059] ksys_write+0x5c/0xc8 [1135630.498638] __arm64_sys_write+0x24/0x30 [1135630.504821] el0_svc_common+0x78/0x130 [1135630.510838] el0_svc_handler+0x38/0x78 [1135630.516834] el0_svc+0x8/0x1b0 kernel/trace/trace_kprobe.c: 1308 0xffff3df8995039ec : ldr x21, [x24,#120] include/linux/compiler.h: 294 0xffff3df8995039f0 : ldr x1, [x21,x0] kernel/trace/trace_kprobe.c 1308: head = this_cpu_ptr(call->perf_events); 1309: if (hlist_empty(head)) 1310: \treturn 0; crash> struct trace_event_call -o struct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ... } crash> struct trace_event_call ffffaf015340e528 struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ... } Race Condition Analysis: The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)← KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL) Problem: 1. CPU0 executes (1) assigning tp_event->perf_events = list 2. CPU0 executes (2) enabling kprobe functionality via class->reg() 3. CPU1 triggers and reaches kprobe_dispatcher 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed) 5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULL CPU1 sees that kprobe functionality is enabled but does not see that perf_events has been assigned. Add pairing read an ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40200", "url": "https://ubuntu.com/security/CVE-2025-40200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: reject negative file sizes in squashfs_read_inode() Syskaller reports a \"WARNING in ovl_copy_up_file\" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip@squashfs.org.uk: only need to check 64 bit quantity]", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40179", "url": "https://ubuntu.com/security/CVE-2025-40179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: verify orphan file size is not too big In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but large orphan files.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40218", "url": "https://ubuntu.com/security/CVE-2025-40218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr: do not repeat pte_offset_map_lock() until success DAMON's virtual address space operation set implementation (vaddr) calls pte_offset_map_lock() inside the page table walk callback function. This is for reading and writing page table accessed bits. If pte_offset_map_lock() fails, it retries by returning the page table walk callback function with ACTION_AGAIN. pte_offset_map_lock() can continuously fail if the target is a pmd migration entry, though. Hence it could cause an infinite page table walk if the migration cannot be done until the page table walk is finished. This indeed caused a soft lockup when CPU hotplugging and DAMON were running in parallel. Avoid the infinite loop by simply not retrying the page table walk. DAMON is promising only a best-effort accuracy, so missing access to such pages is no problem.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40219", "url": "https://ubuntu.com/security/CVE-2025-40219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 (\"PCI: Add global pci_lock_rescan_remove()\") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc (\"PCI/IOV: Factor out sriov_add_vfs()\") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 \t00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 \t0000000000000001 0000000000000000 0000000000000000 0000000180692828 \t00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40193", "url": "https://ubuntu.com/security/CVE-2025-40193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xtensa: simdisk: add input size check in proc_write_simdisk A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash. This follows the same pattern as commit ee76746387f6 (\"netdevsim: prevent bad user input in nsim_dev_health_break_write()\")", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40204", "url": "https://ubuntu.com/security/CVE-2025-40204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40192", "url": "https://ubuntu.com/security/CVE-2025-40192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"ipmi: fix msg stack when IPMI is disconnected\" This reverts commit c608966f3f9c2dca596967501d00753282b395fc. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40188", "url": "https://ubuntu.com/security/CVE-2025-40188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pwm: berlin: Fix wrong register in suspend/resume The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40201", "url": "https://ubuntu.com/security/CVE-2025-40201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40194", "url": "https://ubuntu.com/security/CVE-2025-40194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40205", "url": "https://ubuntu.com/security/CVE-2025-40205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid potential out-of-bounds in btrfs_encode_fh() The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40160", "url": "https://ubuntu.com/security/CVE-2025-40160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/events: Return -EEXIST for bound VIRQs Change find_virq() to return -EEXIST when a VIRQ is bound to a different CPU than the one passed in. With that, remove the BUG_ON() from bind_virq_to_irq() to propogate the error upwards. Some VIRQs are per-cpu, but others are per-domain or global. Those must be bound to CPU0 and can then migrate elsewhere. The lookup for per-domain and global will probably fail when migrated off CPU 0, especially when the current CPU is tracked. This now returns -EEXIST instead of BUG_ON(). A second call to bind a per-domain or global VIRQ is not expected, but make it non-fatal to avoid trying to look up the irq, since we don't know which per_cpu(virq_to_irq) it will be in.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40206", "url": "https://ubuntu.com/security/CVE-2025-40206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_objref: validate objref and objrefmap expressions Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls: BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12) [...] Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 [...] Implement objref and objrefmap expression validate functions. Currently, only NFT_OBJECT_SYNPROXY object type requires validation. This will also handle a jump to a chain using a synproxy object from the OUTPUT hook. Now when trying to reference a synproxy object in the OUTPUT hook, nft will produce the following error: synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40183", "url": "https://ubuntu.com/security/CVE-2025-40183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6} Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40187", "url": "https://ubuntu.com/security/CVE-2025-40187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40111", "url": "https://ubuntu.com/security/CVE-2025-40111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix Use-after-free in validation Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.", "cve_priority": "medium", "cve_public_date": "2025-11-12 02:15:00 UTC" }, { "cve": "CVE-2025-40110", "url": "https://ubuntu.com/security/CVE-2025-40110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a null-ptr access in the cursor snooper Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it. vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean \"no surface\", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it. Fixes unchecked null-ptr reference in the snooping code.", "cve_priority": "medium", "cve_public_date": "2025-11-12 02:15:00 UTC" }, { "cve": "CVE-2025-40001", "url": "https://ubuntu.com/security/CVE-2025-40001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mvsas: Fix use-after-free bugs in mvs_work_queue During the detaching of Marvell's SAS/SATA controller, the original code calls cancel_delayed_work() in mvs_free() to cancel the delayed work item mwq->work_q. However, if mwq->work_q is already running, the cancel_delayed_work() may fail to cancel it. This can lead to use-after-free scenarios where mvs_free() frees the mvs_info while mvs_work_queue() is still executing and attempts to access the already-freed mvs_info. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work item completes before the mvs_info is deallocated. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2025-10-18 08:15:00 UTC" }, { "cve": "CVE-2025-40207", "url": "https://ubuntu.com/security/CVE-2025-40207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try() v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40031", "url": "https://ubuntu.com/security/CVE-2025-40031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: fix register_shm_helper() In register_shm_helper(), fix incorrect error handling for a call to iov_iter_extract_pages(). A case is missing for when iov_iter_extract_pages() only got some pages and return a number larger than 0, but not the requested amount. This fixes a possible NULL pointer dereference following a bad input from ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40037", "url": "https://ubuntu.com/security/CVE-2025-40037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: simplefb: Fix use after free in simplefb_detach_genpds() The pm_domain cleanup can not be devres managed as it uses struct simplefb_par which is allocated within struct fb_info by framebuffer_alloc(). This allocation is explicitly freed by unregister_framebuffer() in simplefb_remove(). Devres managed cleanup runs after the device remove call and thus can no longer access struct simplefb_par. Call simplefb_detach_genpds() explicitly from simplefb_destroy() like the cleanup functions for clocks and regulators. Fixes an use after free on M2 Mac mini during aperture_remove_conflicting_devices() using the downstream asahi kernel with Debian's kernel config. For unknown reasons this started to consistently dereference an invalid pointer in v6.16.3 based kernels. [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220 [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227 [ 6.750697] [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT) [ 6.752189] Call trace: [ 6.752190] show_stack+0x34/0x98 (C) [ 6.752194] dump_stack_lvl+0x60/0x80 [ 6.752197] print_report+0x17c/0x4d8 [ 6.752201] kasan_report+0xb4/0x100 [ 6.752206] __asan_report_load4_noabort+0x20/0x30 [ 6.752209] simplefb_detach_genpds+0x58/0x220 [ 6.752213] devm_action_release+0x50/0x98 [ 6.752216] release_nodes+0xd0/0x2c8 [ 6.752219] devres_release_all+0xfc/0x178 [ 6.752221] device_unbind_cleanup+0x28/0x168 [ 6.752224] device_release_driver_internal+0x34c/0x470 [ 6.752228] device_release_driver+0x20/0x38 [ 6.752231] bus_remove_device+0x1b0/0x380 [ 6.752234] device_del+0x314/0x820 [ 6.752238] platform_device_del+0x3c/0x1e8 [ 6.752242] platform_device_unregister+0x20/0x50 [ 6.752246] aperture_detach_platform_device+0x1c/0x30 [ 6.752250] aperture_detach_devices+0x16c/0x290 [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50 ... [ 6.752343] [ 6.967409] Allocated by task 62: [ 6.970724] kasan_save_stack+0x3c/0x70 [ 6.974560] kasan_save_track+0x20/0x40 [ 6.978397] kasan_save_alloc_info+0x40/0x58 [ 6.982670] __kasan_kmalloc+0xd4/0xd8 [ 6.986420] __kmalloc_noprof+0x194/0x540 [ 6.990432] framebuffer_alloc+0xc8/0x130 [ 6.994444] simplefb_probe+0x258/0x2378 ... [ 7.054356] [ 7.055838] Freed by task 227: [ 7.058891] kasan_save_stack+0x3c/0x70 [ 7.062727] kasan_save_track+0x20/0x40 [ 7.066565] kasan_save_free_info+0x4c/0x80 [ 7.070751] __kasan_slab_free+0x6c/0xa0 [ 7.074675] kfree+0x10c/0x380 [ 7.077727] framebuffer_release+0x5c/0x90 [ 7.081826] simplefb_destroy+0x1b4/0x2c0 [ 7.085837] put_fb_info+0x98/0x100 [ 7.089326] unregister_framebuffer+0x178/0x320 [ 7.093861] simplefb_remove+0x3c/0x60 [ 7.097611] platform_remove+0x60/0x98 [ 7.101361] device_remove+0xb8/0x160 [ 7.105024] device_release_driver_internal+0x2fc/0x470 [ 7.110256] device_release_driver+0x20/0x38 [ 7.114529] bus_remove_device+0x1b0/0x380 [ 7.118628] device_del+0x314/0x820 [ 7.122116] platform_device_del+0x3c/0x1e8 [ 7.126302] platform_device_unregister+0x20/0x50 [ 7.131012] aperture_detach_platform_device+0x1c/0x30 [ 7.136157] aperture_detach_devices+0x16c/0x290 [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50 ...", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40047", "url": "https://ubuntu.com/security/CVE-2025-40047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: always prune wait queue entry in io_waitid_wait() For a successful return, always remove our entry from the wait queue entry list. Previously this was skipped if a cancelation was in progress, but this can race with another invocation of the wait queue entry callback.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40057", "url": "https://ubuntu.com/security/CVE-2025-40057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Add a upper bound on max_vclocks syzbot reported WARNING in max_vclocks_store. This occurs when the argument max is too large for kcalloc to handle. Extend the guard to guard against values that are too large for kcalloc", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40058", "url": "https://ubuntu.com/security/CVE-2025-40058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Disallow dirty tracking if incoherent page walk Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work. The Intel VT-d specification, Section 3.10 \"Snoop Behavior\" states: \"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault.\" To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40059", "url": "https://ubuntu.com/security/CVE-2025-40059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: Fix incorrect handling for return value of devm_kzalloc The return value of devm_kzalloc could be an null pointer, use \"!desc.pdata\" to fix incorrect handling return value of devm_kzalloc.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40155", "url": "https://ubuntu.com/security/CVE-2025-40155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: debugfs: Fix legacy mode page table dump logic In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490 ... Avoid walking the page table if TT is not 00b or 01b.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40079", "url": "https://ubuntu.com/security/CVE-2025-40079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Sign extend struct ops return values properly The ns_bpf_qdisc selftest triggers a kernel panic: Unable to handle kernel paging request at virtual address ffffffffa38dbf58 Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000 [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000 Oops [#1] Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)] CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G W OE 6.17.0-rc1-g2465bb83e0b4 #1 NONE Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024 epc : __qdisc_run+0x82/0x6f0 ra : __qdisc_run+0x6e/0x6f0 epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550 gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180 t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0 s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001 a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000 a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049 s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000 s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0 s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000 s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000 t5 : 0000000000000000 t6 : ff60000093a6a8b6 status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d [] __qdisc_run+0x82/0x6f0 [] __dev_queue_xmit+0x4c0/0x1128 [] neigh_resolve_output+0xd0/0x170 [] ip6_finish_output2+0x226/0x6c8 [] ip6_finish_output+0x10c/0x2a0 [] ip6_output+0x5e/0x178 [] ip6_xmit+0x29a/0x608 [] inet6_csk_xmit+0xe6/0x140 [] __tcp_transmit_skb+0x45c/0xaa8 [] tcp_connect+0x9ce/0xd10 [] tcp_v6_connect+0x4ac/0x5e8 [] __inet_stream_connect+0xd8/0x318 [] inet_stream_connect+0x3e/0x68 [] __sys_connect_file+0x50/0x88 [] __sys_connect+0x96/0xc8 [] __riscv_sys_connect+0x20/0x30 [] do_trap_ecall_u+0x256/0x378 [] handle_exception+0x14a/0x156 Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709 ---[ end trace 0000000000000000 ]--- The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires RISC-V ABI. So let's sign extend struct ops return values according to the function model and RISC-V ABI([0]). [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40000", "url": "https://ubuntu.com/security/CVE-2025-40000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait() There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to access already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 It is a consequence of a race between the waiting and the signaling side of the completion: Waiting thread Completing thread rtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40026", "url": "https://ubuntu.com/security/CVE-2025-40026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended \"recipient\") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-10-28 10:15:00 UTC" }, { "cve": "CVE-2025-40027", "url": "https://ubuntu.com/security/CVE-2025-40027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix double req put in p9_fd_cancelled Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__list_del_entry include/linux/list.h:137 [inline] RIP: 0010:list_del include/linux/list.h:148 [inline] RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734 Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ... Commit 74d6a5d56629 (\"9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work\") fixes a concurrency issue in the 9p filesystem client where the req_list could be deleted simultaneously by both p9_read_work and p9_fd_cancelled functions, but for the case where req->status equals REQ_STATUS_RCVD. Update the check for req->status in p9_fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [updated the check from status == RECV || status == ERROR to status != SENT]", "cve_priority": "medium", "cve_public_date": "2025-10-28 10:15:00 UTC" }, { "cve": "CVE-2025-40109", "url": "https://ubuntu.com/security/CVE-2025-40109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present Ensure that set_ent is always set since only drbg provides it.", "cve_priority": "medium", "cve_public_date": "2025-11-09 05:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40107", "url": "https://ubuntu.com/security/CVE-2025-40107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d (\"can: mcp251x: fix resume from sleep before interface was brought up\"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-11-03 13:15:00 UTC" }, { "cve": "CVE-2025-39995", "url": "https://ubuntu.com/security/CVE-2025-39995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe The state->timer is a cyclic timer that schedules work_i2c_poll and delayed_work_enable_hotplug, while rearming itself. Using timer_delete() fails to guarantee the timer isn't still running when destroyed, similarly cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has terminated if already executing. During probe failure after timer initialization, these may continue running as orphans and reference the already-freed tc358743_state object through tc358743_irq_poll_timer. The following is the trace captured by KASAN. BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace timer_delete() with timer_delete_sync() and cancel_delayed_work() with cancel_delayed_work_sync() to ensure proper termination of timer and work items before resource cleanup. This bug was initially identified through static analysis. For reproduction and testing, I created a functional emulation of the tc358743 device via a kernel module and introduced faults through the debugfs interface.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39994", "url": "https://ubuntu.com/security/CVE-2025-39994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tuner: xc5000: Fix use-after-free in xc5000_release The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was initially identified through static analysis. [hverkuil: fix typo in Subject: tunner -> tuner]", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39991", "url": "https://ubuntu.com/security/CVE-2025-39991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39992", "url": "https://ubuntu.com/security/CVE-2025-39992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap())\t\t\tswapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> \tcopy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). \t\t\t\t 4) swapoff is tried on the \t\t\t\t\t'mm' added to the 'mmlist' as \t\t\t\t\tpart of the 2. \t\t\t\t 5) unuse_mm(), that iterates \t\t\t\t\tthrough the vma's of this 'mm' \t\t\t\t\twill hit the non-NULL zero entry \t\t\t\t\tand operating on this zero entry \t\t\t\t\tas a vma is resulting into the \t\t\t\t\toops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40013", "url": "https://ubuntu.com/security/CVE-2025-40013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: audioreach: fix potential null pointer dereference It is possible that the topology parsing function audioreach_widget_load_module_common() could return NULL or an error pointer. Add missing NULL check so that we do not dereference it.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39996", "url": "https://ubuntu.com/security/CVE-2025-39996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAF This is confirmed by a KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39998", "url": "https://ubuntu.com/security/CVE-2025-39998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: target_core_configfs: Add length check to avoid buffer overflow A buffer overflow arises from the usage of snprintf to write into the buffer \"buf\" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40009", "url": "https://ubuntu.com/security/CVE-2025-40009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: check p->vec_buf for NULL When the PAGEMAP_SCAN ioctl is invoked with vec_len = 0 reaches pagemap_scan_backout_range(), kernel panics with null-ptr-deref: [ 44.936808] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.937797] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 44.938391] CPU: 1 UID: 0 PID: 2480 Comm: reproducer Not tainted 6.17.0-rc6 #22 PREEMPT(none) [ 44.939062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.939935] RIP: 0010:pagemap_scan_thp_entry.isra.0+0x741/0xa80 [ 44.946828] Call Trace: [ 44.947030] [ 44.949219] pagemap_scan_pmd_entry+0xec/0xfa0 [ 44.952593] walk_pmd_range.isra.0+0x302/0x910 [ 44.954069] walk_pud_range.isra.0+0x419/0x790 [ 44.954427] walk_p4d_range+0x41e/0x620 [ 44.954743] walk_pgd_range+0x31e/0x630 [ 44.955057] __walk_page_range+0x160/0x670 [ 44.956883] walk_page_range_mm+0x408/0x980 [ 44.958677] walk_page_range+0x66/0x90 [ 44.958984] do_pagemap_scan+0x28d/0x9c0 [ 44.961833] do_pagemap_cmd+0x59/0x80 [ 44.962484] __x64_sys_ioctl+0x18d/0x210 [ 44.962804] do_syscall_64+0x5b/0x290 [ 44.963111] entry_SYSCALL_64_after_hwframe+0x76/0x7e vec_len = 0 in pagemap_scan_init_bounce_buffer() means no buffers are allocated and p->vec_buf remains set to NULL. This breaks an assumption made later in pagemap_scan_backout_range(), that page_region is always allocated for p->vec_buf_index. Fix it by explicitly checking p->vec_buf for NULL before dereferencing. Other sites that might run into same deref-issue are already (directly or transitively) protected by checking p->vec_buf. Note: From PAGEMAP_SCAN man page, it seems vec_len = 0 is valid when no output is requested and it's only the side effects caller is interested in, hence it passes check in pagemap_scan_get_args(). This issue was found by syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39973", "url": "https://ubuntu.com/security/CVE-2025-39973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: add validation for ring_len param The `ring_len` parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation. To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-38709", "url": "https://ubuntu.com/security/CVE-2025-38709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: loop: Avoid updating block size under exclusive owner Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39967", "url": "https://ubuntu.com/security/CVE-2025-39967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix integer overflow in fbcon_do_set_font Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters. The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying. Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40006", "url": "https://ubuntu.com/security/CVE-2025-40006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix folio is still mapped when deleted Migration may be raced with fallocating hole. remove_inode_single_folio will unmap the folio if the folio is still mapped. However, it's called without folio lock. If the folio is migrated and the mapped pte has been converted to migration entry, folio_mapped() returns false, and won't unmap it. Due to extra refcount held by remove_inode_single_folio, migration fails, restores migration entry to normal pte, and the folio is mapped again. As a result, we triggered BUG in filemap_unaccount_folio. The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):\"my_hugepage_file\" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380 Hold folio lock before checking if the folio is mapped to avold race with migration.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40008", "url": "https://ubuntu.com/security/CVE-2025-40008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kmsan: fix out-of-bounds access to shadow memory Running sha224_kunit on a KMSAN-enabled kernel results in a crash in kmsan_internal_set_shadow_origin(): BUG: unable to handle page fault for address: ffffbc3840291000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1810067 P4D 1810067 PUD 192d067 PMD 3c17067 PTE 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 81 Comm: kunit_try_catch Tainted: G N 6.17.0-rc3 #10 PREEMPT(voluntary) Tainted: [N]=TEST Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmsan_internal_set_shadow_origin+0x91/0x100 [...] Call Trace: __msan_memset+0xee/0x1a0 sha224_final+0x9e/0x350 test_hash_buffer_overruns+0x46f/0x5f0 ? kmsan_get_shadow_origin_ptr+0x46/0xa0 ? __pfx_test_hash_buffer_overruns+0x10/0x10 kunit_try_run_case+0x198/0xa00 This occurs when memset() is called on a buffer that is not 4-byte aligned and extends to the end of a guard page, i.e. the next page is unmapped. The bug is that the loop at the end of kmsan_internal_set_shadow_origin() accesses the wrong shadow memory bytes when the address is not 4-byte aligned. Since each 4 bytes are associated with an origin, it rounds the address and size so that it can access all the origins that contain the buffer. However, when it checks the corresponding shadow bytes for a particular origin, it incorrectly uses the original unrounded shadow address. This results in reads from shadow memory beyond the end of the buffer's shadow memory, which crashes when that memory is not mapped. To fix this, correctly align the shadow address before accessing the 4 shadow bytes corresponding to each origin.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40010", "url": "https://ubuntu.com/security/CVE-2025-40010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix potential null pointer dereference in afs_put_server afs_put_server() accessed server->debug_id before the NULL check, which could lead to a null pointer dereference. Move the debug_id assignment, ensuring we never dereference a NULL server pointer.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40021", "url": "https://ubuntu.com/security/CVE-2025-40021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: dynevent: Add a missing lockdown check on dynevent Since dynamic_events interface on tracefs is compatible with kprobe_events and uprobe_events, it should also check the lockdown status and reject if it is set.", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39968", "url": "https://ubuntu.com/security/CVE-2025-39968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: add max boundary check for VF filters There is no check for max filters that VF can request. Add it.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39969", "url": "https://ubuntu.com/security/CVE-2025-39969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix validation of VF state in get resources VF state I40E_VF_STATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources. Use I40E_VF_STATE_RESOURCES_LOADED that is set only in i40e_vc_get_vf_resources_msg() and cleared during reset.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39970", "url": "https://ubuntu.com/security/CVE-2025-39970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix input validation logic for action_meta Fix condition to check 'greater or equal' to prevent OOB dereference.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39971", "url": "https://ubuntu.com/security/CVE-2025-39971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39972", "url": "https://ubuntu.com/security/CVE-2025-39972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in i40e_validate_queue_map Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map().", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39977", "url": "https://ubuntu.com/security/CVE-2025-39977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent use-after-free during requeue-PI syzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL); In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization. This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section. Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated. Read futex_q::task before updating the requeue state, use it for the following wakeup.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40011", "url": "https://ubuntu.com/security/CVE-2025-40011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix null dereference in hdmi teardown pci_set_drvdata sets the value of pdev->driver_data to NULL, after which the driver_data obtained from the same dev is dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is extracted from it. To prevent this, swap these calls. Found by Linux Verification Center (linuxtesting.org) with Svacer.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39978", "url": "https://ubuntu.com/security/CVE-2025-39978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow() This code calls kfree_rcu(new_node, rcu) and then dereferences \"new_node\" and then dereferences it on the next line. Two lines later, we take a mutex so I don't think this is an RCU safe region. Re-order it to do the dereferences before queuing up the free.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39980", "url": "https://ubuntu.com/security/CVE-2025-39980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Forbid FDB status change while nexthop is in a group The kernel forbids the creation of non-FDB nexthop groups with FDB nexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops. And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops. However, as long as no routes are pointing to a non-FDB nexthop group, the kernel allows changing the type of a nexthop from FDB to non-FDB and vice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0 This configuration is invalid and can result in a NPD [1] since FDB nexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1 Fix by preventing nexthop FDB status change while the nexthop is in a group: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group. [1] BUG: kernel NULL pointer dereference, address: 00000000000003c0 [...] Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:fib_lookup_good_nhc+0x1e/0x80 [...] Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40024", "url": "https://ubuntu.com/security/CVE-2025-40024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost: Take a reference on the task in struct vhost_task. vhost_task_create() creates a task and keeps a reference to its task_struct. That task may exit early via a signal and its task_struct will be released. A pending vhost_task_wake() will then attempt to wake the task and access a task_struct which is no longer there. Acquire a reference on the task_struct while creating the thread and release the reference while the struct vhost_task itself is removed. If the task exits early due to a signal, then the vhost_task_wake() will still access a valid task_struct. The wake is safe and will be skipped in this case.", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39982", "url": "https://ubuntu.com/security/CVE-2025-39982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync This fixes the following UFA in hci_acl_create_conn_sync where a connection still pending is command submission (conn->state == BT_OPEN) maybe freed, also since this also can happen with the likes of hci_le_create_conn_sync fix it as well: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541 CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci3 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40020", "url": "https://ubuntu.com/security/CVE-2025-40020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: fix shift-out-of-bounds issue Explicitly uses a 64-bit constant when the number of bits used for its shifting is 32 (which is the case for PC CAN FD interfaces supported by this driver). [mkl: update subject, apply manually]", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39985", "url": "https://ubuntu.com/security/CVE-2025-39985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the mcba_usb driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on these lines: \tusb_msg.dlc = cf->len; \tmemcpy(usb_msg.data, cf->data, usb_msg.dlc); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39986", "url": "https://ubuntu.com/security/CVE-2025-39986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, sun4ican_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on this line: \tdlc = cf->len; Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs a couple line below when doing: \tfor (i = 0; i < dlc; i++) \t\twritel(cf->data[i], priv->base + (dreg + i * 4)); Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39987", "url": "https://ubuntu.com/security/CVE-2025-39987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. The driver will consume frame->len as-is with no further checks. This can result in a buffer overflow later on in hi3110_hw_tx() on this line: \tmemcpy(buf + HI3110_FIFO_EXT_DATA_OFF, \t frame->data, frame->len); Here, frame->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39988", "url": "https://ubuntu.com/security/CVE-2025-39988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the etas_es58x driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)); to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, es58x_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN(FD) frame. This can result in a buffer overflow. For example, using the es581.4 variant, the frame will be dispatched to es581_4_tx_can_msg(), go through the last check at the beginning of this function: \tif (can_is_canfd_skb(skb)) \t\treturn -EMSGSIZE; and reach this line: \tmemcpy(tx_can_msg->data, cf->data, cf->len); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU or CANFD_MTU (depending on the device capabilities). By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39932", "url": "https://ubuntu.com/security/CVE-2025-39932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work) In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again. I actually just hit the case using rxe: WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10 [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ... It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39940", "url": "https://ubuntu.com/security/CVE-2025-39940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stripe: fix a possible integer overflow There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39948", "url": "https://ubuntu.com/security/CVE-2025-39948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix Rx page leak on multi-buffer frames The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver. It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed. If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf(). Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc. The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page. Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with \"jumbo frames\" used by 9K MTU. To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts(). Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() on the last buffer of the frame indicating the end of packet. For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss. The xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame. Move the increment of the ntc local variable to ensure its updated *before* all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic requires the index of the element just after the current frame. Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rx_ring.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39950", "url": "https://ubuntu.com/security/CVE-2025-39950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR A NULL pointer dereference can occur in tcp_ao_finish_connect() during a connect() system call on a socket with a TCP-AO key added and TCP_REPAIR enabled. The function is called with skb being NULL and attempts to dereference it on tcp_hdr(skb)->seq without a prior skb validation. Fix this by checking if skb is NULL before dereferencing it. The commentary is taken from bpf_skops_established(), which is also called in the same flow. Unlike the function being patched, bpf_skops_established() validates the skb before dereferencing it. int main(void){ \tstruct sockaddr_in sockaddr; \tstruct tcp_ao_add tcp_ao; \tint sk; \tint one = 1; \tmemset(&sockaddr,'\\0',sizeof(sockaddr)); \tmemset(&tcp_ao,'\\0',sizeof(tcp_ao)); \tsk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); \tsockaddr.sin_family = AF_INET; \tmemcpy(tcp_ao.alg_name,\"cmac(aes128)\",12); \tmemcpy(tcp_ao.key,\"ABCDEFGHABCDEFGH\",16); \ttcp_ao.keylen = 16; \tmemcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); \tsetsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao, \tsizeof(tcp_ao)); \tsetsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one)); \tsockaddr.sin_family = AF_INET; \tsockaddr.sin_port = htobe16(123); \tinet_aton(\"127.0.0.1\", &sockaddr.sin_addr); \tconnect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr)); return 0; } $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall $ unshare -Urn BUG: kernel NULL pointer dereference, address: 00000000000000b6 PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39961", "url": "https://ubuntu.com/security/CVE-2025-39961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd/pgtbl: Fix possible race while increase page table level The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] \t\t\t\t\t Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.", "cve_priority": "medium", "cve_public_date": "2025-10-09 13:15:00 UTC" }, { "cve": "CVE-2025-22106", "url": "https://ubuntu.com/security/CVE-2025-22106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: unregister xdp rxq info in the reset path vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace. Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0 This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39934", "url": "https://ubuntu.com/security/CVE-2025-39934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39937", "url": "https://ubuntu.com/security/CVE-2025-39937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda (\"net: rfkill: gpio: get the name and type from device property\") rfkill_find_type() gets called with the possibly uninitialized \"const char *type_name;\" local variable. On x86 systems when rfkill-gpio binds to a \"BCM4752\" or \"LNV4752\" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no \"type\" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a \"BCM4752\"/\"LNV4752\" acpi_device 2. The stack happened to contain NULL where type_name is stored", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39938", "url": "https://ubuntu.com/security/CVE-2025-39938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and \"dai_data->graph[dai->id]\" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39942", "url": "https://ubuntu.com/security/CVE-2025-39942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size This is inspired by the check for data_offset + data_length.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39943", "url": "https://ubuntu.com/security/CVE-2025-39943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: validate data_offset and data_length field of smb_direct_data_transfer If data_offset and data_length of smb_direct_data_transfer struct are invalid, out of bounds issue could happen. This patch validate data_offset and data_length field in recv_done.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39944", "url": "https://ubuntu.com/security/CVE-2025-39944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp() The original code relies on cancel_delayed_work() in otx2_ptp_destroy(), which does not ensure that the delayed work item synctstamp_work has fully completed if it was already running. This leads to use-after-free scenarios where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp(). Furthermore, the synctstamp_work is cyclic, the likelihood of triggering the bug is nonnegligible. A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAF This is confirmed by a KASAN report: BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800aa09a18 by task bash/136 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled before the otx2_ptp is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced artificial delays within the otx2_sync_tstamp() function to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39945", "url": "https://ubuntu.com/security/CVE-2025-39945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cnic: Fix use-after-free bugs in cnic_delete_task The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39955", "url": "https://ubuntu.com/security/CVE-2025-39955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect(). syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk in the TCP_ESTABLISHED state. [0] syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destination As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes it to TCP_CLOSE and makes connect() possible, which restarts timers. Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the retransmit timer triggered the warning and the intended packet was not retransmitted. Let's call reqsk_fastopen_remove() in tcp_disconnect(). [0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) ", "cve_priority": "medium", "cve_public_date": "2025-10-09 10:15:00 UTC" }, { "cve": "CVE-2025-39947", "url": "https://ubuntu.com/security/CVE-2025-39947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Harden uplink netdev access against device unbind The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39949", "url": "https://ubuntu.com/security/CVE-2025-39949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qed: Don't collect too many protection override GRC elements In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer. This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESS where \"ADDRESS\" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure. The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783 or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663 Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39951", "url": "https://ubuntu.com/security/CVE-2025-39951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: virtio_uml: Fix use-after-free after put_device in probe When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39953", "url": "https://ubuntu.com/security/CVE-2025-39953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: split cgroup_destroy_wq into 3 workqueues A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction. Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio Call Trace: \tcgroup_lock_and_drain_offline+0x14c/0x1e8 \tcgroup_destroy_root+0x3c/0x2c0 \tcss_free_rwork_fn+0x248/0x338 \tprocess_one_work+0x16c/0x3b8 \tworker_thread+0x22c/0x3b0 \tkthread+0xec/0x100 \tret_from_fork+0x10/0x20 Root Cause: CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues \t\t\t\t// cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1) Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation This separation eliminates blocking in the CSS free path while waiting for offline operations to complete. [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39957", "url": "https://ubuntu.com/security/CVE-2025-39957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: increase scan_ies_len for S1G Currently the S1G capability element is not taken into account for the scan_ies_len, which leads to a buffer length validation failure in ieee80211_prep_hw_scan() and subsequent WARN in __ieee80211_start_scan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length.", "cve_priority": "medium", "cve_public_date": "2025-10-09 10:15:00 UTC" }, { "cve": "CVE-2025-39952", "url": "https://ubuntu.com/security/CVE-2025-39952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: avoid buffer overflow in WID string configuration Fix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537) This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39927", "url": "https://ubuntu.com/security/CVE-2025-39927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix race condition validating r_parent before applying state Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39923", "url": "https://ubuntu.com/security/CVE-2025-39923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2]. Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs. [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/ [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39869", "url": "https://ubuntu.com/security/CVE-2025-39869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map Fix a critical memory allocation bug in edma_setup_from_hw() where queue_priority_map was allocated with insufficient memory. The code declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8), but allocated memory using sizeof(s8) instead of the correct size. This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i; The bug manifested as kernel crashes with \"Oops - undefined instruction\" on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the memory corruption triggered kernel hardening features on Clang. Change the allocation to use sizeof(*queue_priority_map) which automatically gets the correct size for the 2D array structure.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39873", "url": "https://ubuntu.com/security/CVE-2025-39873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB can_put_echo_skb() takes ownership of the SKB and it may be freed during or after the call. However, xilinx_can xcan_write_frame() keeps using SKB after the call. Fix that by only calling can_put_echo_skb() after the code is done touching the SKB. The tx_lock is held for the entire xcan_write_frame() execution and also on the can_get_echo_skb() side so the order of operations does not matter. An earlier fix commit 3d3c817c3a40 (\"can: xilinx_can: Fix usage of skb memory\") did not move the can_put_echo_skb() call far enough. [mkl: add \"commit\" in front of sha1 in patch description] [mkl: fix indention]", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39911", "url": "https://ubuntu.com/security/CVE-2025-39911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration later than the first, the error path wants to free the IRQs requested so far. However, it uses the wrong dev_id argument for free_irq(), so it does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]--- Use the same dev_id for free_irq() as for request_irq(). I tested this with inserting code to fail intentionally.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39876", "url": "https://ubuntu.com/security/CVE-2025-39876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() The function of_phy_find_device may return NULL, so we need to take care before dereferencing phy_dev.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39881", "url": "https://ubuntu.com/security/CVE-2025-39881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernfs: Fix UAF in polling when open file is released A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism: BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1 psi_trigger_poll+0x3c/0x140 cgroup_pressure_poll+0x70/0xa0 cgroup_file_poll+0x8c/0x100 kernfs_fop_poll+0x11c/0x1c0 ep_item_poll.isra.0+0x188/0x2c0 Allocated by task 1: cgroup_file_open+0x88/0x388 kernfs_fop_open+0x73c/0xaf0 do_dentry_open+0x5fc/0x1200 vfs_open+0xa0/0x3f0 do_open+0x7e8/0xd08 path_openat+0x2fc/0x6b0 do_filp_open+0x174/0x368 Freed by task 8462: cgroup_file_release+0x130/0x1f8 kernfs_drain_open_files+0x17c/0x440 kernfs_drain+0x2dc/0x360 kernfs_show+0x1b8/0x288 cgroup_file_show+0x150/0x268 cgroup_pressure_write+0x1dc/0x340 cgroup_file_write+0x274/0x548 Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv epolling\t\t\tdisable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epoll_wait kernfs_fop_poll kernfs_get_active = true\techo 0 > cgroup.pressure ...\t\t\t\tcgroup_file_show \t\t\t\tkernfs_show \t\t\t\t// inactive kn \t\t\t\tkernfs_drain_open_files \t\t\t\tcft->release(of); \t\t\t\tkfree(ctx); \t\t\t\t... kernfs_get_active = false \t\t\t\techo 1 > cgroup.pressure \t\t\t\tkernfs_show \t\t\t\tkernfs_activate_one(kn); kernfs_fop_poll kernfs_get_active = true cgroup_file_poll psi_trigger_poll // UAF ... end: close(fd) To address this issue, introduce kernfs_get_active_of() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfs_get_active() with kernfs_get_active_of() to prevent further operations on released file descriptors.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39909", "url": "https://ubuntu.com/security/CVE-2025-39909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters() Patch series \"mm/damon: avoid divide-by-zero in DAMON module's parameters application\". DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors. Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters. This patch (of 2): During the calculation of 'hot_thres' and 'cold_thres', either 'sample_interval' or 'aggr_interval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggr_interval' is already required to be set no smaller than 'sample_interval' in damon_set_attrs(), only the case where 'sample_interval' is zero needs to be checked.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39916", "url": "https://ubuntu.com/security/CVE-2025-39916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters() When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39877", "url": "https://ubuntu.com/security/CVE-2025-39877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: fix use-after-free in state_show() state_show() reads kdamond->damon_ctx without holding damon_sysfs_lock. This allows a use-after-free race: CPU 0 CPU 1 ----- ----- state_show() damon_sysfs_turn_damon_on() ctx = kdamond->damon_ctx; mutex_lock(&damon_sysfs_lock); damon_destroy_ctx(kdamond->damon_ctx); kdamond->damon_ctx = NULL; mutex_unlock(&damon_sysfs_lock); damon_is_running(ctx); /* ctx is freed */ mutex_lock(&ctx->kdamond_lock); /* UAF */ (The race can also occur with damon_sysfs_kdamonds_rm_dirs() and damon_sysfs_kdamond_release(), which free or replace the context under damon_sysfs_lock.) Fix by taking damon_sysfs_lock before dereferencing the context, mirroring the locking used in pid_show(). The bug has existed since state_show() first accessed kdamond->damon_ctx.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39880", "url": "https://ubuntu.com/security/CVE-2025-39880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix invalid accesses to ceph_connection_v1_info There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use). On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets. con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39883", "url": "https://ubuntu.com/security/CVE-2025-39883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory When I did memory failure tests, below panic occurs: page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 Modules linked in: hwpoison_inject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- The root cause is that unpoison_memory() tries to check the PG_HWPoison flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps: 1.Offline memory block: echo offline > /sys/devices/system/memory/memory12/state 2.Get offlined memory pfn: page-types -b n -rlN 3.Write pfn to unpoison-pfn echo > /sys/kernel/debug/hwpoison/unpoison-pfn This scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail if pfn_to_online_page() == NULL to fix the bug.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39907", "url": "https://ubuntu.com/security/CVE-2025-39907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer Avoid below overlapping mappings by using a contiguous non-cacheable buffer. [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST, overlapping mappings aren't supported [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300 [ 4.097071] Modules linked in: [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1 [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT) [ 4.118824] Workqueue: events_unbound deferred_probe_work_func [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.131624] pc : add_dma_entry+0x23c/0x300 [ 4.135658] lr : add_dma_entry+0x23c/0x300 [ 4.139792] sp : ffff800009dbb490 [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000 [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8 [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20 [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006 [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58 [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000 [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40 [ 4.214185] Call trace: [ 4.216605] add_dma_entry+0x23c/0x300 [ 4.220338] debug_dma_map_sg+0x198/0x350 [ 4.224373] __dma_map_sg_attrs+0xa0/0x110 [ 4.228411] dma_map_sg_attrs+0x10/0x2c [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174 [ 4.242127] nand_read_oob+0x1d4/0x8e0 [ 4.245861] mtd_read_oob_std+0x58/0x84 [ 4.249596] mtd_read_oob+0x90/0x150 [ 4.253231] mtd_read+0x68/0xac", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39885", "url": "https://ubuntu.com/security/CVE-2025-39885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix recursive semaphore deadlock in fiemap call syzbot detected a OCFS2 hang due to a recursive semaphore on a FS_IOC_FIEMAP of the extent list on a specially crafted mmap file. context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline] RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline] RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline] RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26 Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89 f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41 RSP: 0018:ffffc9000403f950 EFLAGS: 00050256 RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038 RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060 RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42 R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098 R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f13850fd9 RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9 RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004 RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0 R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the extent list of this running mmap executable. The user supplied buffer to hold the fiemap information page faults calling ocfs2_page_mkwrite() which will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same semaphore. This recursive semaphore will hold filesystem locks and causes a hang of the fileystem. The ip_alloc_sem protects the inode extent list and size. Release the read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap() and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock on the last extent but simplifies the error path.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39913", "url": "https://ubuntu.com/security/CVE-2025-39913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork. syzbot reported the splat below. [0] The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytes At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes(). Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN. If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc(). Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork. The \"*copied\" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets \"*copied\" to 0. [0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 ", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39886", "url": "https://ubuntu.com/security/CVE-2025-39886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init() Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example: ... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ... The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event. We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc. As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there. Depends on mm patch \"memcg: skip cgroup_file_notify if spinning is not allowed\": https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/ v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39914", "url": "https://ubuntu.com/security/CVE-2025-39914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Silence warning when chunk allocation fails in trace_pid_write Syzkaller trigger a fault injection warning: WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning. The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-23143", "url": "https://ubuntu.com/security/CVE-2025-23143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod. When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1] Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule At step 3), the CIFS module calls sock_release() for the underlying TCP socket, and it returns quickly. However, the socket remains in FIN_WAIT_1 because incoming FIN packets are dropped. At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sock_release() and it returns, the TCP socket does not die immediately in order to close the connection gracefully. While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sk_lock using sock_lock_init_class_and_name(). Once an incoming packet is processed for the socket or a timer fires, sk->sk_lock is acquired. Then, LOCKDEP checks the lock context in check_wait_context(), where hlock_class() is called to retrieve the lock class. However, since the module has already been unloaded, hlock_class() logs a warning and returns NULL, triggering the null-ptr-deref. If LOCKDEP is enabled, we must ensure that a module calling sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue. Let's hold the module reference in sock_lock_init_class_and_name() and release it when the socket is freed in sk_prot_free(). Note that sock_lock_init() clears sk->sk_owner for svc_create_socket() that calls sock_lock_init_class_and_name() for a listening socket, which clones a socket by sk_clone_lock() without GFP_ZERO. [0]: CIFS_SERVER=\"10.0.0.137\" CIFS_PATH=\"//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST\" DEV=\"enp0s3\" CRED=\"/root/WindowsCredential.txt\" MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire (kernel/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-22124", "url": "https://ubuntu.com/security/CVE-2025-22124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb In clustermd, separate write-intent-bitmaps are used for each cluster node: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal to bitmap->storage.file_pages. Then bitmap_limit will be calculated to 0. md_super_write() will be called with 0 size. That means the first 4k sb area of node 1 will never be updated through filemap_write_page(). This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize. Here use (pg_index % bitmap->storage.file_pages) to make calculation of bitmap_limit correct.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-23133", "url": "https://ubuntu.com/security/CVE-2025-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: update channel list in reg notifier instead reg worker Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list(). But ath11k will immediately execute step 3 after reg_work is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0 Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set, cfg80211 will notify ath11k after step 2 is done. So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/ Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22113", "url": "https://ubuntu.com/security/CVE-2025-22113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid journaling sb update on error if journal is destroying Presently we always BUG_ON if trying to start a transaction on a journal marked with JBD2_UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for update_super_work to start a transaction after the journal is destroyed eg: (umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super \tflush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT) Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit. Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updates This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc86606) Also, we don't need a similar check in ext4_grp_locked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22125", "url": "https://ubuntu.com/security/CVE-2025-22125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: don't ignore IO flags If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced. Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks. Fix those problems by keep IO flags from master bio. Fises: f51d46d0e7cb (\"md: add support for REQ_NOWAIT\")", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39899", "url": "https://ubuntu.com/security/CVE-2025-39899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using kmap_local_page(), which requires unmapping in Last-In-First-Out order. The current code maps dst_pte first, then src_pte, but unmaps them in the same order (dst_pte, src_pte), violating the LIFO requirement. This causes the warning in kunmap_local_indexed(): WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c addr \\!= __fix_to_virt(FIX_KMAP_BEGIN + idx) Fix this by reversing the unmap order to respect LIFO ordering. This issue follows the same pattern as similar fixes: - commit eca6828403b8 (\"crypto: skcipher - fix mismatch between mapping and unmapping order\") - commit 8cf57c6df818 (\"nilfs2: eliminate staggered calls to kunmap in nilfs_rename\") Both of which addressed the same fundamental requirement that kmap_local operations must follow LIFO ordering.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39897", "url": "https://ubuntu.com/security/CVE-2025-39897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Add error handling for RX metadata pointer retrieval Add proper error checking for dmaengine_desc_get_metadata_ptr() which can return an error pointer and lead to potential crashes or undefined behaviour if the pointer retrieval fails. Properly handle the error by unmapping DMA buffer, freeing the skb and returning early to prevent further processing with invalid data.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39850", "url": "https://ubuntu.com/security/CVE-2025-39850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects When the \"proxy\" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the \"any\" remote (0.0.0.0 / ::). The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4]. Fix by checking that the remote destination exists before dereferencing it. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3 [3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77 [4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39851", "url": "https://ubuntu.com/security/CVE-2025-39851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD when refreshing an FDB entry with a nexthop object VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39852", "url": "https://ubuntu.com/security/CVE-2025-39852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm \"softirq\", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need to be called. They make sure the newsk will end up being correctly free'd. tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit label that takes care of things. So, this patch here makes sure tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar error-handling and thus fixes the leak for TCP-AO.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39901", "url": "https://ubuntu.com/security/CVE-2025-39901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: remove read access to debugfs files The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c (\"i40e: debugfs interface\"). Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here. On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be \": \". For 'netdev_ops', this will be \": \". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism. We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc. A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input. Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once. In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39854", "url": "https://ubuntu.com/security/CVE-2025-39854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the \"low latency\" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same \"ready\" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-38556", "url": "https://ubuntu.com/security/CVE-2025-38556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Harden s32ton() against conversion to 0 bits Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38502", "url": "https://ubuntu.com/security/CVE-2025-38502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix oob access in cgroup local storage Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf); For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access. To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.", "cve_priority": "medium", "cve_public_date": "2025-08-16 10:15:00 UTC" }, { "cve": "CVE-2025-39843", "url": "https://ubuntu.com/security/CVE-2025-39843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: slub: avoid wake up kswapd in set_track_prepare set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock. Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since ___slab_alloc() has preemption disabled, we mask out __GFP_DIRECT_RECLAIM from the flags there. The oops looks something like: BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c ___slab_alloc+0xccc __kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39920", "url": "https://ubuntu.com/security/CVE-2025-39920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pcmcia: Add error handling for add_interval() in do_validate_mem() In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next. This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39902", "url": "https://ubuntu.com/security/CVE-2025-39902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slub: avoid accessing metadata when pointer is invalid in object_err() object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object. One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process. In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39838", "url": "https://ubuntu.com/security/CVE-2025-39838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: prevent NULL pointer dereference in UTF16 conversion There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash. This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer. Found by Linux Verification Center (linuxtesting.org) with SVACE", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39839", "url": "https://ubuntu.com/security/CVE-2025-39839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix OOB read/write in network-coding decode batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write. Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39841", "url": "https://ubuntu.com/security/CVE-2025-39841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix buffer free/clear order in deferred receive path Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39891", "url": "https://ubuntu.com/security/CVE-2025-39891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Initialize the chan_stats array to zero The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey(). There are two potential issues here. What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak. Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc().", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39842", "url": "https://ubuntu.com/security/CVE-2025-39842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: prevent release journal inode after journal shutdown Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode(). ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> \t jbd2_journal_release_jbd_inode(osb->journal->j_journal, Adding osb->journal checks will prevent null-ptr-deref during the above execution path.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39895", "url": "https://ubuntu.com/security/CVE-2025-39895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: Fix sched_numa_find_nth_cpu() if mask offline sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer. The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline): [ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000 [ 1.423635] Mem abort info: [ 1.423889] ESR = 0x0000000096000006 [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.424715] SET = 0, FnV = 0 [ 1.424995] EA = 0, S1PTW = 0 [ 1.425279] FSC = 0x06: level 2 translation fault [ 1.425735] Data abort info: [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000 [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000 [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP [ 1.429525] Modules linked in: [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT) [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488 [ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488 [ 1.432543] sp : ffffffc084e1b960 [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0 [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378 [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7 [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372 [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860 [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000 [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68 [ 1.439332] Call trace: [ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P) [ 1.440016] smp_call_function_any+0xc8/0xd0 [ 1.440416] armv8_pmu_init+0x58/0x27c [ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c [ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8 [ 1.441603] armv8_pmu_device_probe+0x1c/0x28 [ 1.442007] platform_probe+0x5c/0xac [ 1.442347] really_probe+0xbc/0x298 [ 1.442683] __driver_probe_device+0x78/0x12c [ 1.443087] driver_probe_device+0xdc/0x160 [ 1.443475] __driver_attach+0x94/0x19c [ 1.443833] bus_for_each_dev+0x74/0xd4 [ 1.444190] driver_attach+0x24/0x30 [ 1.444525] bus_add_driver+0xe4/0x208 [ 1.444874] driver_register+0x60/0x128 [ 1.445233] __platform_driver_register+0x24/0x30 [ 1.445662] armv8_pmu_driver_init+0x28/0x4c [ 1.446059] do_one_initcall+0x44/0x25c [ 1.446416] kernel_init_freeable+0x1dc/0x3bc [ 1.446820] kernel_init+0x20/0x1d8 [ 1.447151] ret_from_fork+0x10/0x20 [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803) [ 1.448040] ---[ end trace 0000000000000000 ]--- [ 1.448483] note: swapper/0[1] exited with preempt_count 1 [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.449741] SMP: stopping secondary CPUs [ 1.450105] Kernel Offset: disabled [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b [ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39844", "url": "https://ubuntu.com/security/CVE-2025-39844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: move page table sync declarations to linux/pgtable.h During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 (\"x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes\")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39845", "url": "https://ubuntu.com/security/CVE-2025-39845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure page tables are properly synchronized when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...]", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39846", "url": "https://ubuntu.com/security/CVE-2025-39846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region() In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39847", "url": "https://ubuntu.com/security/CVE-2025-39847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix memory leak in pad_compress_skb If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop; drop: kfree_skb(skb); When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak. Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39848", "url": "https://ubuntu.com/security/CVE-2025-39848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: properly unshare skbs in ax25_kiss_rcv() Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d (\"net: introduce per netns packet chains\"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without a major crash. But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not. Many thanks to Bernard Pidoux for his help, diagnosis and tests. We had a similar issue years ago fixed with commit 7aaed57c5c28 (\"phonet: properly unshare skbs in phonet_rcv()\").", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39849", "url": "https://ubuntu.com/security/CVE-2025-39849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39853", "url": "https://ubuntu.com/security/CVE-2025-39853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39857", "url": "https://ubuntu.com/security/CVE-2025-39857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc] ... Call Trace: smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 If the software RoCE device is used, ibdev->dma_device is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39860", "url": "https://ubuntu.com/security/CVE-2025-39860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() syzbot reported the splat below without a repro. In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that. The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit. bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release(). Two threads could see the same socket during the list iteration in bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF Depending on the timing, the other thread could show up in the \"Freed by task\" part. Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release(). [0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39861", "url": "https://ubuntu.com/security/CVE-2025-39861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: vhci: Prevent use-after-free by removing debugfs files early Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed. Previously, debugfs files such as \"force_suspend\", \"force_wakeup\", and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors. Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39894", "url": "https://ubuntu.com/security/CVE-2025-39894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39864", "url": "https://ubuntu.com/security/CVE-2025-39864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix use-after-free in cmp_bss() Following bss_free() quirk introduced in commit 776b3580178f (\"cfg80211: track hidden SSID networks properly\"), adjust cfg80211_update_known_bss() to free the last beacon frame elements only if they're not shared via the corresponding 'hidden_beacon_bss' pointer.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39865", "url": "https://ubuntu.com/security/CVE-2025-39865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: fix NULL pointer dereference in tee_shm_put tee_shm_put have NULL pointer dereference: __optee_disable_shm_cache --> \tshm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> \t\ttee_shm_put(shm);//crash Add check in tee_shm_put to fix it. panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39866", "url": "https://ubuntu.com/security/CVE-2025-39866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix use-after-free in __mark_inode_dirty() An use-after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching. CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 ...... pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mark_inode_dirty+0x124/0x418 lr : __mark_inode_dirty+0x118/0x418 sp : ffffffc08c9dbbc0 ........ Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198 Root cause is: systemd-random-seed kworker ---------------------------------------------------------------------- ___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39811", "url": "https://ubuntu.com/security/CVE-2025-39811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Clear the scratch_pt pointer on error Avoid triggering a dereference of an error pointer on cleanup in xe_vm_free_scratch() by clearing any scratch_pt error pointer. (cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8)", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39815", "url": "https://ubuntu.com/security/CVE-2025-39815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: fix stack overrun when loading vlenb The userspace load can put up to 2048 bits into an xlen bit stack buffer. We want only xlen bits, so check the size beforehand.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39836", "url": "https://ubuntu.com/security/CVE-2025-39836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efi: stmm: Fix incorrect buffer allocation method The communication buffer allocated by setup_mm_hdr() is later on passed to tee_shm_register_kernel_buf(). The latter expects those buffers to be contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause various corruptions or BUGs, specifically since commit 9aec2fb0fd5e (\"slab: allocate frozen pages\"), though it was broken before as well. Fix this by using alloc_pages_exact() instead of kmalloc().", "cve_priority": "medium", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39805", "url": "https://ubuntu.com/security/CVE-2025-39805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix unregister_netdev call order in macb_remove() When removing a macb device, the driver calls phy_exit() before unregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ... The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus. Fix this by moving unregister_netdev() ahead of phy_exit() in macb_remove().", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39829", "url": "https://ubuntu.com/security/CVE-2025-39829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: trace/fgraph: Fix the warning caused by missing unregister notifier This warning was triggered during testing on v6.16: notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written. Fixed by adding unregister_pm_notifier in the exception path.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39835", "url": "https://ubuntu.com/security/CVE-2025-39835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: do not propagate ENODATA disk errors into xattr code ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found. However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as \"attribute not found\" when in fact it's an IO (disk) error. At worst, we may oops in xfs_attr_leaf_get() when we do: \terror = xfs_attr_leaf_hasname(args, &bp); \tif (error == -ENOATTR) { \t\txfs_trans_brelse(args->trans, bp); \t\treturn error; \t} because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfs_trans_brelse will then null-deref it. As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don't let unique errors like this leak up into higher xfs functions - many like this should be remapped to EIO. However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later. (Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.)", "cve_priority": "low", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39819", "url": "https://ubuntu.com/security/CVE-2025-39819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb: Fix inconsistent refcnt update A possible inconsistent update of refcount was identified in `smb2_compound_op`. Such inconsistent update could lead to possible resource leaks. Why it is a possible bug: 1. In the comment section of the function, it clearly states that the reference to `cfile` should be dropped after calling this function. 2. Every control flow path would check and drop the reference to `cfile`, except the patched one. 3. Existing callers would not handle refcount update of `cfile` if -ENOMEM is returned. To fix the bug, an extra goto label \"out\" is added, to make sure that the cleanup logic would always be respected. As the problem is caused by the allocation failure of `vars`, the cleanup logic between label \"finished\" and \"out\" can be safely ignored. According to the definition of function `is_replayable_error`, the error code of \"-ENOMEM\" is not recoverable. Therefore, the replay logic also gets ignored.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39808", "url": "https://ubuntu.com/security/CVE-2025-39808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version() in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58) add null check logic to ntrig_report_version() before calling hid_to_usb_dev()", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39806", "url": "https://ubuntu.com/security/CVE-2025-39806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it. Below is the KASAN splat after the out of bounds access happens: [ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 [...]", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39824", "url": "https://ubuntu.com/security/CVE-2025-39824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix UAF via HID_CLAIMED_INPUT validation After hid_hw_start() is called hidinput_connect() will eventually be called to set up the device with the input layer since the HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect() all input and output reports are processed and corresponding hid_inputs are allocated and configured via hidinput_configure_usages(). This process involves slot tagging report fields and configuring usages by setting relevant bits in the capability bitmaps. However it is possible that the capability bitmaps are not set at all leading to the subsequent hidinput_has_been_populated() check to fail leading to the freeing of the hid_input and the underlying input device. This becomes problematic because a malicious HID device like a ASUS ROG N-Key keyboard can trigger the above scenario via a specially crafted descriptor which then leads to a user-after-free when the name of the freed input device is written to later on after hid_hw_start(). Below, report 93 intentionally utilises the HID_UP_UNDEFINED Usage Page which is skipped during usage configuration, leading to the frees. 0x05, 0x0D, // Usage Page (Digitizer) 0x09, 0x05, // Usage (Touch Pad) 0xA1, 0x01, // Collection (Application) 0x85, 0x0D, // Report ID (13) 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) 0x09, 0xC5, // Usage (0xC5) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x04, // Report Count (4) 0xB1, 0x02, // Feature (Data,Var,Abs) 0x85, 0x5D, // Report ID (93) 0x06, 0x00, 0x00, // Usage Page (Undefined) 0x09, 0x01, // Usage (0x01) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x1B, // Report Count (27) 0x81, 0x02, // Input (Data,Var,Abs) 0xC0, // End Collection Below is the KASAN splat after triggering the UAF: [ 21.672709] ================================================================== [ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80 [ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54 [ 21.673700] [ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary) [ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 21.673700] Call Trace: [ 21.673700] [ 21.673700] dump_stack_lvl+0x5f/0x80 [ 21.673700] print_report+0xd1/0x660 [ 21.673700] kasan_report+0xe5/0x120 [ 21.673700] __asan_report_store8_noabort+0x1b/0x30 [ 21.673700] asus_probe+0xeeb/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 [...] [ 21.673700] [ 21.673700] Allocated by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_alloc_info+0x3b/0x50 [ 21.673700] __kasan_kmalloc+0x9c/0xa0 [ 21.673700] __kmalloc_cache_noprof+0x139/0x340 [ 21.673700] input_allocate_device+0x44/0x370 [ 21.673700] hidinput_connect+0xcb6/0x2630 [ 21.673700] hid_connect+0xf74/0x1d60 [ 21.673700] hid_hw_start+0x8c/0x110 [ 21.673700] asus_probe+0x5a3/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 [...] [ 21.673700] [ 21.673700] Freed by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_free_info+0x3f/0x60 [ 21.673700] __kasan_slab_free+0x3c/0x50 [ 21.673700] kfre ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39823", "url": "https://ubuntu.com/security/CVE-2025-39823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: use array_index_nospec with indices that come from guest min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39817", "url": "https://ubuntu.com/security/CVE-2025-39817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare Observed on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0 If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename: T1\t\t\tT2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list \t\t\tlookup_open \t\t\t d_alloc_parallel \t\t\t __d_lookup_rcu \t\t\t __d_lookup_rcu_op_compare \t\t\t hlist_bl_for_each_entry_rcu \t\t\t // invalid dentry can be retrieved \t\t\t ->d_compare \t\t\t efivarfs_d_compare \t\t\t // oob Fix it by checking 'guid' before cmp.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39812", "url": "https://ubuntu.com/security/CVE-2025-39812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: initialize more fields in sctp_v6_from_sk() syzbot found that sin6_scope_id was not properly initialized, leading to undefined behavior. Clear sin6_scope_id and sin6_flowinfo. BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39827", "url": "https://ubuntu.com/security/CVE-2025-39827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: include node references in rose_neigh refcount Current implementation maintains two separate reference counting mechanisms: the 'count' field in struct rose_neigh tracks references from rose_node structures, while the 'use' field (now refcount_t) tracks references from rose_sock. This patch merges these two reference counting systems using 'use' field for proper reference management. Specifically, this patch adds incrementing and decrementing of rose_neigh->use when rose_neigh->count is incremented or decremented. This patch also modifies rose_rt_free(), rose_rt_device_down() and rose_clear_route() to properly release references to rose_neigh objects before freeing a rose_node through rose_remove_node(). These changes ensure rose_neigh structures are properly freed only when all references, including those from rose_node structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39826", "url": "https://ubuntu.com/security/CVE-2025-39826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: convert 'use' field to refcount_t The 'use' field in struct rose_neigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a rose_neigh structure is freed while still being referenced by other code paths. For example, when rose_neigh->use becomes zero during an ioctl operation via rose_rt_ioctl(), the structure may be removed while its timer is still active, potentially causing use-after-free issues. This patch changes the type of 'use' from unsigned short to refcount_t and updates all code paths to use rose_neigh_hold() and rose_neigh_put() which operate reference counts atomically.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39832", "url": "https://ubuntu.com/security/CVE-2025-39832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix lockdep assertion on sync reset unload event Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning. Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39828", "url": "https://ubuntu.com/security/CVE-2025-39828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control(). syzbot reported the splat below. [0] When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message. The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc. The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer. struct atmtcp_control { \tstruct atmtcp_hdr hdr;\t/* must be first */ ... \tatm_kptr_t vcc;\t\t/* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t; The special message is processed in atmtcp_recv_control() called from atmtcp_c_send(). atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control. Let's add a new ->pre_send() hook to validate messages from sendmsg(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 Modules linked in:", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39697", "url": "https://ubuntu.com/security/CVE-2025-39697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39825", "url": "https://ubuntu.com/security/CVE-2025-39825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix race with concurrent opens in rename(2) Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file. Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39813", "url": "https://ubuntu.com/security/CVE-2025-39813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix potential warning in trace_printk_seq during ftrace_dump When calling ftrace_dump_one() concurrently with reading trace_pipe, a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race condition. The issue occurs because: CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger !trace_empty(&iter) trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipe trace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULL trace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size) In the context between trace_empty() and trace_find_next_entry_inc() during ftrace_dump, the ring buffer data was consumed by other readers. This caused trace_find_next_entry_inc to return NULL, failing to populate `iter.seq`. At this point, due to the prior trace_iterator_reset, both `iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal, the WARN_ON_ONCE condition is triggered. Move the trace_printk_seq() into the if block that checks to make sure the return value of trace_find_next_entry_inc() is non-NULL in ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before subsequent operations.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-37899", "url": "https://ubuntu.com/security/CVE-2025-37899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in session logoff The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-22037", "url": "https://ubuntu.com/security/CVE-2025-22037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference in alloc_preauth_hash() The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauth_info is not allocated. This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-103.103 -proposed tracker (LP: #2141411)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * xhci_find_slot_id_by_port kernel panic on boot on arm64 (LP: #2141314)", " - Revert \"xhci: fix stale flag preventig URBs after link state error is", " cleared\"", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - thunderbolt: Show path name in debug log when path is deactivated", " - thunderbolt: Log path activation failures without WARN backtraces", "", " * x86: tsc: Fix TSC clock source being disabled when SNC is enabled causing", " fall back to less precise HPET (LP: #2138120)", " - x86/tsc: Use topology_max_packages() to get package number", "", " * Random flickering with Intel i915 (CoffeeLake and WhiskeyLake) on Linux", " 6.8 (LP: #2136958)", " - SAUCE: iommu/intel: disable DMAR for CFL and WHL integrated gfx", "", " * CXL: Fix slab-out-of-bounds in cxl_setup_parent_dport (LP: #2130240)", " - cxl/pci: Get AER capability address from RCRB only for RCH dport", " - cxl/test: Skip cxl_setup_parent_dport() for emulated dports", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633)", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: lan966x: Fix the initialization of taprio", " - net/mlx5e: Fix validation logic in rate limiting", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - net: dsa: sja1105: simplify static configuration reload", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: pcc: Refactor error handling in irq handler into separate", " function", " - mailbox: pcc: don't zero error register", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-mem: Allow specifying the byte order in Octal DTR mode", " - spi: spi-mem: Extend spi-mem operations with a per-operation maximum", " frequency", " - spi: spi-mem: Add a new controller capability", " - spi: nxp-fspi: Support per spi-mem operation frequency switches", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - mptcp: clear scheduled subflows on retransmit", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - nfsd: Replace clamp_t in nfsd4_get_drc_mem()", " - usb: udc: Add trace event for usb_gadget_set_state", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - can: rcar_canfd: Fix CAN-FD mode as default", " - iio: adc: rtq6056: Correct the sign bit index", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - drm/amd/display: Don't change brightness for disabled connectors", " - KVM: SVM: Introduce svm_recalc_lbr_msr_intercepts()", " - KVM: nSVM: Always recalculate LBR MSR intercepts in svm_update_lbrv()", " - KVM: nSVM: Fix and simplify LBR virtualization handling with nested", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - wifi: ath12k: correctly handle mcast packets for clients", " - drm/i915/dp: Initialize the source OUI write timestamp always", " - SAUCE: bpf: introduce __MAX_BPF_PROG_TYPE delimiter", " - Upstream stable to v6.6.119, v6.12.61", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624)", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - smb: client: introduce close_cached_dir_locked()", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix premature close in case of fallback", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - bcma: don't register devices disabled in OF", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: net: use BASH for bareudp testing", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - f2fs: compress: change the first parameter of page_array_{alloc,free} to", " sbi", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - uio_hv_generic: Set event for all channels on the device", " - maple_tree: fix tracepoint string pointers", " - selftests: mptcp: join: endpoints: longer transfer", " - HID: amd_sfh: Stop sensor before starting", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - mptcp: fix duplicate reset on fastclose", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - xfrm: set err and extack on failure to create pcpu SA", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - selftests: net: lib: Do not overwrite error messages", " - af_unix: Cache state->msg in unix_stream_read_generic().", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: tls: Change async resync helpers argument", " - ALSA: usb-audio: Fix missing unlock at error path of maxpacksize check", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - tty/vt: fix up incorrect backport to stable releases", " - Upstream stable to v6.6.118, v6.12.60", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68198", " - crash: fix crashkernel resource shrink", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-38627", " - f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460)", " - net: usb: asix_devices: Check return value of usbnet_get_endpoints", " - fbdev: atyfb: Check if pll_ops->init_pll failed", " - ACPI: button: Call input_free_device() on failing input device", " registration", " - Bluetooth: rfcomm: fix modem control handling", " - fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS", " - fbdev: valkyriefb: Fix reference count leak in valkyriefb_init", " - mptcp: drop bogus optimization in __mptcp_check_push()", " - mptcp: restore window probe", " - ASoC: qdsp6: q6asm: do not sleep while atomic", " - wifi: ath10k: Fix memory leak on unsupported WMI command", " - wifi: ath11k: Add missing platform IDs for quirk table", " - wifi: ath12k: free skb during idr cleanup callback", " - drm/msm/a6xx: Fix GMU firmware parser", " - ALSA: usb-audio: fix control pipe direction", " - scsi: ufs: core: Initialize value of an attribute returned by uic cmd", " - ASoC: Intel: avs: Unprepare a stream when XRUN occurs", " - ASoC: fsl_sai: fix bit order for DSD format", " - libbpf: Fix powerpc's stack register definition in bpf_tracing.h", " - Bluetooth: btmtksdio: Add pmctrl handling for BT closed state during", " reset", " - Bluetooth: HCI: Fix tracking of advertisement set/instance 0x00", " - Bluetooth: ISO: Fix another instance of dst_type handling", " - Bluetooth: hci_core: Fix tracking of periodic advertisement", " - drm/etnaviv: fix flush sequence logic", " - net: hns3: return error code when function fails", " - sfc: fix potential memory leak in efx_mae_process_mport()", " - drm/amd/pm: fix smu table id bound check issue in smu_cmn_update_table()", " - drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji", " - drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Iceland", " - block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL", " - block: make REQ_OP_ZONE_OPEN a write operation", " - drm/mediatek: Fix device use-after-free on unbind", " - mptcp: fix MSG_PEEK stream corruption", " - cpuidle: governors: menu: Rearrange main loop in menu_select()", " - cpuidle: governors: menu: Select polling state in some more cases", " - net: phy: dp83867: Disable EEE support as not implemented", " - [Config] disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP for s390x", " - drm/sched: Fix race in drm_sched_entity_select_rq()", " - soc: aspeed: socinfo: Add AST27xx silicon IDs", " - soc: qcom: smem: Fix endian-unaware access of num_entries", " - spi: loopback-test: Don't use %pK through printk", " - bpf: Don't use %pK through printk", " - pinctrl: single: fix bias pull up/down handling in pin_config_set", " - mmc: host: renesas_sdhi: Fix the actual clock", " - memstick: Add timeout to prevent indefinite waiting", " - irqchip/sifive-plic: Respect mask state when setting affinity", " - selftests/bpf: Fix bpf_prog_detach2 usage in test_lirc_mode2", " - arc: Fix __fls() const-foldability via __builtin_clzl()", " - selftests/bpf: Upon failures, exit with code 1 in test_xsk.sh", " - irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment", " - ACPI: PRM: Skip handlers with NULL handler_address or NULL VA", " - ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids[]", " - power: supply: qcom_battmgr: add OOI chemistry", " - hwmon: (k10temp) Add device ID for Strix Halo", " - hwmon: (sbtsi_temp) AMD CPU extended temperature range support", " - pinctrl: keembay: release allocated memory in detach path", " - power: supply: sbs-charger: Support multiple devices", " - hwmon: sy7636a: add alias", " - irqchip/loongson-pch-lpc: Use legacy domain for PCH-LPC IRQ controller", " - arm64: zynqmp: Revert usb node drive strength and slew rate for zcu106", " - soc/tegra: fuse: Add Tegra114 nvmem cells and fuse lookups", " - ARM: tegra: transformer-20: add missing magnetometer interrupt", " - ARM: tegra: transformer-20: fix audio-codec interrupt", " - mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card", " - ACPICA: dispatcher: Use acpi_ds_clear_operands() in", " acpi_ds_call_control_method()", " - tee: allow a driver to allocate a tee_device without a pool", " - bpf: Do not limit bpf_cgroup_from_id to current's namespace", " - video: backlight: lp855x_bl: Set correct EPROM start for LP8556", " - tools/cpupower: fix error return value in cpupower_write_sysfs()", " - pmdomain: apple: Add \"apple,t8103-pmgr-pwrstate\"", " - power: supply: qcom_battmgr: handle charging state change notifications", " - bpftool: Fix -Wuninitialized-const-pointer warnings with clang >= 21", " - cpuidle: Fail cpuidle device registration if there is one already", " - spi: rpc-if: Add resume support for RZ/G3E", " - clocksource/drivers/vf-pit: Replace raw_readl/writel to readl/writel", " - riscv: bpf: Fix uninitialized symbol 'retval_off'", " - bpf: Clear pfmemalloc flag when freeing all fragments", " - nvme: Use non zero KATO for persistent discovery connections", " - uprobe: Do not emulate/sstep original instruction when ip is changed", " - hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex", " - hwmon: (dell-smm) Add support for Dell OptiPlex 7040", " - tools/cpupower: Fix incorrect size in cpuidle_state_disable()", " - tools/power x86_energy_perf_policy: Fix incorrect fopen mode usage", " - tools/power x86_energy_perf_policy: Enhance HWP enable", " - tools/power x86_energy_perf_policy: Prefer driver HWP limits", " - mfd: stmpe: Remove IRQ domain upon removal", " - mfd: stmpe-i2c: Add missing MODULE_LICENSE", " - mfd: madera: Work around false-positive -Wininitialized warning", " - mfd: da9063: Split chip variant reading in two bus transactions", " - drm/amd/display: ensure committing streams is seamless", " - drm/amd/display: Increase AUX Intra-Hop Done Max Wait Duration", " - drm/amd/display: add more cyan skillfish devices", " - drm/amd/display: update dpp/disp clock from smu clock table", " - drm/amd/pm: Use cached metrics data on aldebaran", " - drm/amd/pm: Use cached metrics data on arcturus", " - drm/amdgpu/jpeg: Hold pg_lock before jpeg poweroff", " - drm/nouveau: replace snprintf() with scnprintf() in nvkm_snprintbf()", " - PCI: Disable MSI on RDC PCI to PCIe bridges", " - selftests/net: Replace non-standard __WORDSIZE with sizeof(long) * 8", " - selftests/net: Ensure assert() triggers in psock_tpacket.c", " - wifi: rtw88: sdio: use indirect IO for device registers before power-on", " - drm/amdkfd: return -ENOTTY for unsupported IOCTLs", " - media: pci: ivtv: Don't create fake v4l2_fh", " - media: amphion: Delete v4l2_fh synchronously in .release()", " - drm/tidss: Use the crtc_* timings when programming the HW", " - drm/bridge: cdns-dsi: Fix REG_WAKEUP_TIME value", " - drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST", " - drm/tidss: Set crtc modesetting parameters with adjusted mode", " - media: i2c: Kconfig: Ensure a dependency on HAVE_CLK for", " VIDEO_CAMERA_SENSOR", " - x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall", " - net: stmmac: Check stmmac_hw_setup() in stmmac_resume()", " - ice: Don't use %pK through printk or tracepoints", " - thunderbolt: Use is_pciehp instead of is_hotplug_bridge", " - powerpc/eeh: Use result of error_detected() in uevent", " - s390/pci: Use pci_uevent_ers() in PCI recovery", " - bridge: Redirect to backup port when port is administratively down", " - scsi: ufs: host: mediatek: Fix auto-hibern8 timer configuration", " - scsi: ufs: host: mediatek: Assign power mode userdata before FASTAUTO", " mode change", " - scsi: ufs: host: mediatek: Change reset sequence for improved stability", " - scsi: ufs: host: mediatek: Fix invalid access in vccqx handling", " - drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts", " - drm/amdkfd: Handle lack of READ permissions in SVM mapping", " - iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg sample before", " setting register", " - iio: adc: imx93_adc: load calibrated values even calibration failed", " - usb: gadget: f_ncm: Fix MAC assignment NCM ethernet", " - char: misc: Make misc_register() reentry for miscdevice who wants", " dynamic minor", " - char: misc: Does not request module for miscdevice with dynamic minor", " - net: When removing nexthops, don't call synchronize_net if it is not", " necessary", " - net: Call trace_sock_exceed_buf_limit() for memcg failure with", " SK_MEM_RECV.", " - PCI/P2PDMA: Fix incorrect pointer usage in devm_kfree() call", " - ALSA: usb-audio: Add validation of UAC2/UAC3 effect units", " - rds: Fix endianness annotation for RDS_MPATH_HASH", " - scsi: mpi3mr: Fix controller init failure on fault during queue creation", " - scsi: pm80xx: Fix race condition caused by static variables", " - extcon: adc-jack: Fix wakeup source leaks on device unbind", " - remoteproc: wkup_m3: Use devm_pm_runtime_enable() helper", " - net: phy: fixed_phy: let fixed_phy_unregister free the phy_device", " - fuse: zero initialize inode private data", " - drm/amdkfd: fix vram allocation failure for a special case", " - drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption", " - media: fix uninitialized symbol warnings", " - drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)", " - mips: lantiq: danube: add missing properties to cpu node", " - mips: lantiq: danube: add model to EASY50712 dts", " - mips: lantiq: danube: add missing device_type in pci node", " - mips: lantiq: xway: sysctrl: rename stp clock", " - mips: lantiq: danube: rename stp node on EASY50712 reference board", " - crypto: qat - use kcalloc() in qat_uclo_map_objs_from_mof()", " - scsi: pm8001: Use int instead of u32 to store error codes", " - ptp: Limit time setting of PTP clocks", " - dmaengine: sh: setup_xref error handling", " - dmaengine: mv_xor: match alloc_wc and free_wc", " - dmaengine: dw-edma: Set status for callback_result", " - drm/msm/dsi/phy: Toggle back buffer resync after preparing PLL", " - drm/msm/dsi/phy_7nm: Fix missing initial VCO rate", " - drm/amdgpu: Allow kfd CRIU with no buffer objects", " - ipv6: Add sanity checks on ipv6_devconf.rpl_seg_enabled", " - net: nfc: nci: Increase NCI_DATA_TIMEOUT to 3000 ms", " - media: adv7180: Add missing lock in suspend callback", " - media: adv7180: Do not write format to device in set_fmt", " - media: adv7180: Only validate format in querystd", " - media: verisilicon: Explicitly disable selection api ioctls for decoders", " - ALSA: usb-audio: apply quirk for MOONDROP Quark2", " - net: call cond_resched() less often in __release_sock()", " - smsc911x: add second read of EEPROM mac when possible corruption seen", " - iommu/apple-dart: Clear stream error indicator bits for T8110 DARTs", " - drm/amd: add more cyan skillfish PCI ids", " - drm/amdgpu: don't enable SMU on cyan skillfish", " - drm/amdgpu: add support for cyan skillfish gpu_info", " - usb: gadget: f_hid: Fix zero length packet transfer", " - drm/msm: make sure to not queue up recovery more than once", " - char: Use list_del_init() in misc_deregister() to reinitialize list", " pointer", " - media: ov08x40: Fix the horizontal flip control", " - media: i2c: og01a1b: Specify monochrome media bus format instead of", " Bayer", " - scsi: ufs: host: mediatek: Enhance recovery on resume failure", " - scsi: ufs: host: mediatek: Enhance recovery on hibernation exit failure", " - net: phy: marvell: Fix 88e1510 downshift counter errata", " - scsi: ufs: host: mediatek: Disable auto-hibern8 during power mode", " changes", " - wifi: mac80211: Fix HE capabilities element check", " - phy: cadence: cdns-dphy: Enable lower resolutions in dphy", " - phy: renesas: r8a779f0-ether-serdes: add new step added to latest", " datasheet", " - phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf register 0", " - net: sh_eth: Disable WoL if system can not suspend", " - selftests: net: replace sleeps in fcnal-test with waits", " - media: redrat3: use int type to store negative error codes", " - selftests: traceroute: Use require_command()", " - netfilter: nf_reject: don't reply to icmp error messages", " - x86/kvm: Prefer native qspinlock for dedicated vCPUs irrespective of", " PV_UNHALT", " - selftests: Disable dad for ipv6 in fcnal-test.sh", " - eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT_MAP", " - [Config] disable 8139TOO_PIO for armhf", " - selftests: Replace sleep with slowwait", " - HID: asus: add Z13 folio to generic group for multitouch to work", " - watchdog: s3c2410_wdt: Fix max_timeout being calculated larger", " - crypto: sun8i-ce - remove channel timeout field", " - PCI: dwc: Verify the single eDMA IRQ in dw_pcie_edma_irq_verify()", " - crypto: caam - double the entropy delay interval for retry", " - net/cls_cgroup: Fix task_get_classid() during qdisc run", " - wifi: mt76: mt7921: Add 160MHz beamformee capability for mt7922 device", " - wifi: mt76: mt7996: Temporarily disable EPCS", " - ALSA: serial-generic: remove shared static buffer", " - drm/amdgpu: Use memdup_array_user in amdgpu_cs_wait_fences_ioctl", " - drm/amd: Avoid evicting resources at S5", " - drm/amd/display: Fix DVI-D/HDMI adapters", " - drm/amd/display: Disable VRR on DCE 6", " - ethernet: Extend device_get_mac_address() to use NVMEM", " - HID: i2c-hid: Resolve touchpad issues on Dell systems during S4", " - drm/amdgpu: reject gang submissions under SRIOV", " - selftests/Makefile: include $(INSTALL_DEP_TARGETS) in clean target to", " clean net/lib dependency", " - scsi: ufs: core: Disable timestamp functionality if not supported", " - scsi: lpfc: Check return status of lpfc_reset_flush_io_context during", " TGT_RESET", " - scsi: lpfc: Remove ndlp kref decrement clause for F_Port_Ctrl in", " lpfc_cleanup", " - scsi: lpfc: Define size of debugfs entry for xri rebalancing", " - allow finish_no_open(file, ERR_PTR(-E...))", " - usb: mon: Increase BUFF_MAX to 64 MiB to support multi-MB URBs", " - usb: xhci: plat: Facilitate using autosuspend for xhci plat devices", " - ipv6: np->rxpmtu race annotation", " - ASoC: qcom: sc8280xp: explicitly set S16LE format in", " sc8280xp_be_hw_params_fixup()", " - net: phy: clear link parameters on admin link down", " - net: ethernet: microchip: sparx5: make it selectable for ARCH_LAN969X", " - iommu/vt-d: Replace snprintf with scnprintf in dmar_latency_snapshot()", " - wifi: ath10k: Fix connection after GTK rekeying", " - net: intel: fm10k: Fix parameter idx set but not used", " - sparc/module: Add R_SPARC_UA64 relocation handling", " - sparc64: fix prototypes of reads[bwl]()", " - vfio: return -ENOTTY for unsupported device feature", " - PCI/PM: Skip resuming to D0 if device is disconnected", " - remoteproc: qcom: q6v5: Avoid handling handover twice", " - wifi: ath12k: Increase DP_REO_CMD_RING_SIZE to 256", " - drm/amd/display: Add AVI infoframe copy in copy_stream_update_to_stream", " - NFSv4: handle ERR_GRACE on delegation recalls", " - NFSv4.1: fix mount hang after CREATE_SESSION failure", " - net: bridge: Install FDB for bridge MAC on VLAN 0", " - scsi: libfc: Fix potential buffer overflow in fc_ct_ms_fill()", " - accel/habanalabs/gaudi2: fix BMON disable configuration", " - scsi: mpt3sas: Add support for 22.5 Gbps SAS link rate", " - accel/habanalabs: return ENOMEM if less than requested pages were pinned", " - accel/habanalabs/gaudi2: read preboot status after recovering from dirty", " state", " - fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock", " - ext4: increase IO priority of fastcommit", " - ASoC: stm32: sai: manage context in set_sysclk callback", " - ASoC: tlv320aic3x: Fix class-D initialization for tlv320aic3007", " - net/mlx5e: Don't query FEC statistics when FEC is disabled", " - net: macb: avoid dealing with endianness in macb_set_hwaddr()", " - Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI", " frames", " - ALSA: usb-audio: add mono main switch to Presonus S1824c", " - exfat: limit log print for IO error", " - 6pack: drop redundant locking and refcounting", " - page_pool: Clamp pool size to max 16K pages", " - ksmbd: use sock_create_kern interface to create kernel socket", " - smb: client: transport: avoid reconnects triggered by pending task work", " - char: misc: restrict the dynamic range to exclude reserved minors", " - ACPICA: Update dsmethod.c to get rid of unused variable warning", " - RDMA/irdma: Fix SD index calculation", " - RDMA/irdma: Remove unused struct irdma_cq fields", " - RDMA/irdma: Set irdma_cq cq_num field during CQ create", " - RDMA/hns: Fix the modification of max_send_sge", " - RDMA/hns: Fix wrong WQE data when QP wraps around", " - btrfs: mark dirty extent range for out of bound prealloc extents", " - fs/hpfs: Fix error code for new_inode() failure in", " mkdir/create/mknod/symlink", " - um: Fix help message for ssl-non-raw", " - clk: sunxi-ng: sun6i-rtc: Add A523 specifics", " - rtc: pcf2127: clear minute/second interrupt", " - ARM: at91: pm: save and restore ACR during PLL disable/enable", " - clk: at91: clk-master: Add check for divide by 3", " - clk: at91: clk-sam9x60-pll: force write to PLL_UPDT register", " - clk: ti: am33xx: keep WKUP_DEBUGSS_CLKCTRL enabled", " - NTB: epf: Allow arbitrary BAR mapping", " - 9p: fix /sys/fs/9p/caches overwriting itself", " - cpufreq: tegra186: Initialize all cores to max frequencies", " - 9p: sysfs_init: don't hardcode error to ENOMEM", " - scsi: ufs: core: Include UTP error in INT_FATAL_ERRORS", " - ACPI: property: Return present device nodes only on fwnode interface", " - tools bitmap: Add missing asm-generic/bitsperlong.h include", " - tools: lib: thermal: don't preserve owner in install", " - tools: lib: thermal: use pkg-config to locate libnl3", " - rtc: pcf2127: fix watchdog interrupt mask on pcf2131", " - kbuild: uapi: Strip comments before size type check", " - ASoC: meson: aiu-encoder-i2s: fix bit clock polarity", " - ceph: add checking of wait_for_completion_killable() return value", " - ceph: refactor wake_up_bit() pattern of calling", " - ALSA: hda/realtek: Audio disappears on HP 15-fc000 after warm boot again", " - media: uvcvideo: Use heuristic to find stream entity", " - net: libwx: fix device bus LAN ID", " - riscv: Improve exception and system call latency", " - riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro", " - Bluetooth: btrtl: Fix memory leak in rtlbt_parse_firmware_v2()", " - net: dsa: tag_brcm: legacy: fix untagged rx on unbridged ports for", " bcm63xx", " - selftests/net: fix out-of-order delivery of FIN in gro:tcp test", " - selftests/net: use destination options instead of hop-by-hop", " - netdevsim: add Makefile for selftests", " - selftests: netdevsim: Fix ethtool-coalesce.sh fail by installing", " ethtool-common.sh", " - net: vlan: sync VLAN features with lower device", " - net: dsa: b53: fix resetting speed and pause on forced link", " - net: dsa: b53: fix enabling ip multicast", " - net: dsa: b53: stop reading ARL entries if search is done", " - sctp: Hold RCU read lock while iterating over address list", " - sctp: Hold sock lock while iterating over address list", " - bnxt_en: Fix a possible memory leak in bnxt_ptp_init", " - wifi: mac80211_hwsim: Limit destroy_on_close radio removal to netgroup", " - net/mlx5e: Use extack in get module eeprom by page callback", " - net/mlx5e: Fix return value in case of module EEPROM read error", " - net/mlx5e: SHAMPO, Fix skb size check for 64K pages", " - net: dsa: microchip: Fix reserved multicast address table programming", " - net: bridge: fix MST static key usage", " - tracing: Fix memory leaks in create_field_var()", " - drm/amd/display: Enable mst when it's detected but yet to be initialized", " - rtc: rx8025: fix incorrect register reference", " - x86/microcode/AMD: Add more known models to entry sign checking", " - smb: client: validate change notify buffer before copy", " - lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC", " - scsi: ufs: ufs-pci: Fix S0ix/S3 for Intel controllers", " - extcon: adc-jack: Cleanup wakeup source only if it was enabled", " - drm/amdgpu: Fix function header names in amdgpu_connectors.c", " - drm/amd/display: Fix black screen with HDMI outputs", " - riscv: stacktrace: fix backtracing through exceptions", " - selftests: netdevsim: set test timeout to 10 minutes", " - drm/i915: Fix conversion between clock ticks and nanoseconds", " - smb: client: fix refcount leak in smb2_set_path_attr", " - iommufd: Make vfio_compat's unmap succeed if the range is already empty", " - drm/amd: Fix suspend failure with secure display TA", " - compiler_types: Move unused static inline functions warning to W=2", " - RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid", " rfence errors", " - riscv: acpi: avoid errors caused by probing DT devices when ACPI is used", " - drm/amd/pm: Disable MCLK switching on SI at high pixel clocks", " - NFS4: Fix state renewals missing after boot", " - HID: quirks: avoid Cooler Master MM712 dongle wakeup bug", " - NFS: check if suid/sgid was cleared after a write as needed", " - HID: quirks: Add ALWAYS_POLL quirk for VRS R295 steering wheel", " - ASoC: max98090/91: fixed max98091 ALSA widget powering up/down", " - wifi: ath11k: zero init info->status in wmi_process_mgmt_tx_comp()", " - selftests: net: local_termination: Wait for interfaces to come up", " - net: fec: correct rx_bytes statistic for the case SHIFT16 is set", " - Bluetooth: 6lowpan: fix BDADDR_LE vs ADDR_LE_DEV address type confusion", " - Bluetooth: 6lowpan: Don't hold spin lock over sleeping functions", " - net/smc: fix mismatch between CLC header and proposal", " - net/handshake: Fix memory leak in tls_handshake_accept()", " - net: mdio: fix resource leak in mdiobus_register_device()", " - wifi: mac80211: skip rate verification for not captured PSDUs", " - net_sched: act_connmark: use RCU in tcf_connmark_dump()", " - net/mlx5e: Fix maxrate wraparound in threshold between units", " - net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps", " - net/mlx5e: Fix potentially misleading debug message", " - net_sched: limit try_bulk_dequeue_skb() batches", " - virtio-net: fix incorrect flags recording in big mode", " - hsr: Fix supervision frame sending on HSRv0", " - ACPI: CPPC: Check _CPC validity for only the online CPUs", " - ACPI: CPPC: Perform fast check switch only for online CPUs", " - ACPI: CPPC: Limit perf ctrs in PCC check only to online CPUs", " - Bluetooth: L2CAP: export l2cap_chan_hold for modules", " - cifs: stop writeback extension when change of size is detected", " - cifs: Fix uncached read into ITER_KVEC iterator", " - acpi,srat: Fix incorrect device handle check for Generic Initiator", " - regulator: fixed: fix GPIO descriptor leak on register failure", " - ASoC: cs4271: Fix regulator leak on probe failure", " - ASoC: codecs: va-macro: fix resource leak in probe error path", " - ASoC: tas2781: fix getting the wrong device number", " - pnfs: Fix TLS logic in _nfs4_pnfs_v4_ds_connect()", " - NFS: enable nconnect for RDMA", " - pnfs: Set transport security policy to RPC_XPRTSEC_NONE unless using TLS", " - NFS: sysfs: fix leak when nfs_client kobject add fails", " - NFSv4: Fix an incorrect parameter when calling nfs4_call_sync()", " - acpi/hmat: Fix lockdep warning for hmem_register_resource()", " - irqchip/riscv-intc: Add missing free() callback in riscv_intc_domain_ops", " - lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN", " - mtd: onenand: Pass correct pointer to IRQ handler", " - arm64: dts: rockchip: Set correct pinctrl for I2S1 8ch TX on odroid-m1", " - ARM: dts: imx51-zii-rdu1: Fix audmux node names", " - HID: hid-ntrig: Prevent memory leak in ntrig_report_version()", " - ARM: dts: BCM53573: Fix address of Luxul XAP-1440's Ethernet PHY", " - HID: uclogic: Fix potential memory leak in error path", " - KVM: SVM: Mark VMCB_LBR dirty when MSR_IA32_DEBUGCTLMSR is updated", " - gcov: add support for GCC 15", " - strparser: Fix signed/unsigned mismatch bug", " - dma-mapping: benchmark: Restore padding to ensure uABI remained", " consistent", " - LoongArch: Use correct accessor to read FWPC/MWPC", " - LoongArch: Let {pte,pmd}_modify() record the status of _PAGE_DIRTY", " - selftests/tracing: Run sample events to clear page cache events", " - wifi: mac80211: reject address change while connecting", " - mm/mm_init: fix hash table order logging in alloc_large_system_hash()", " - mmc: sdhci-of-dwcmshc: Change DLL_STRBIN_TAPNUM_DEFAULT to 0x4", " - crypto: hisilicon/qm - Fix device reference leak in qm_get_qos_value", " - smb: client: fix cifs_pick_channel when channel needs reconnect", " - spi: Try to get ACPI GPIO IRQ earlier", " - x86/microcode/AMD: Add Zen5 model 0x44, stepping 0x1 minrev", " - selftests/user_events: fix type cast for write_index packed member in", " perf_test", " - LoongArch: Use physical addresses for CSR_MERRENTRY/CSR_TLBRENTRY", " - EDAC/altera: Handle OCRAM ECC enable after warm reset", " - EDAC/altera: Use INTTEST register for Ethernet and USB SBE injection", " - btrfs: scrub: put bio after errors in scrub_raid56_parity_stripe()", " - btrfs: do not update last_log_commit when logging inode due to a new", " name", " - pmdomain: samsung: plug potential memleak during probe", " - selftests: mptcp: connect: fix fallback note due to OoO", " - selftests: mptcp: join: rm: set backup flag", " - selftests: mptcp: connect: trunc: read all recv data", " - Revert \"perf dso: Add missed dso__put to dso__load_kcore\"", " - mm, percpu: do not consider sleepable allocations atomic", " - netpoll: remove netpoll_srcu", " - net: netpoll: Individualize the skb pool", " - net: netpoll: flush skb pool during cleanup", " - scsi: ufs: core: Add UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE", " - scsi: ufs: core: fold ufshcd_clear_keyslot() into its caller", " - scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_CRYPTO_ENABLE", " - scsi: ufs: core: Add fill_crypto_prdt variant op", " - scsi: ufs: core: Add UFSHCD_QUIRK_KEYS_IN_PRDT", " - scsi: ufs: core: Add a quirk for handling broken LSDBS field in", " controller capabilities register", " - scsi: ufs: core: Add a quirk to suppress link_startup_again", " - scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel", " ADL", " - filemap: cap PTE range to be created to allowed zero fill in", " folio_map_range()", " - mm/memory: do not populate page table entries beyond i_size", " - mm/truncate: unmap large folio on split failure", " - net: netpoll: ensure skb_pool list is always initialized", " - memory tiers: use default_dram_perf_ref_source in log message", " - memcg: fix data-race KCSAN bug in rstats", " - s390/pci: Restore IRQ unconditionally for the zPCI device", " - wifi: ath11k: add support for MU EDCA", " - wifi: ath11k: avoid bit operation on key flags", " - wifi: mac80211: don't mark keys for inactive links as uploaded", " - wifi: mac80211: fix key tailroom accounting leak", " - kunit: test_dev_action: Correctly cast 'priv' pointer to long*", " - bpf: Find eligible subprogs for private stack support", " - bpf, x86: Avoid repeated usage of bpf_prog->aux->stack_depth", " - bpf: Do not audit capability check in do_jit()", " - Bluetooth: ISO: Update hci_conn_hash_lookup_big for Broadcast slave", " - Bluetooth: ISO: Fix BIS connection dst_type handling", " - dpll: spec: add missing module-name and clock-id to pin-get reply", " - ASoC: fsl_sai: Fix sync error in consumer mode", " - ACPI: fan: Use ACPI handle when retrieving _FST", " - drm/sched: avoid killing parent entity on child SIGKILL", " - drm/nouveau: Fix race in nouveau_sched_fini()", " - drm/ast: Clear preserved bits from register output value", " - drm/amd: Check that VPE has reached DPM0 in idle handler", " - drm/amd/display: Fix incorrect return of vblank enable on unconfigured", " crtc", " - firmware: qcom: scm: preserve assign_mem() error return value", " - soc: ti: pruss: don't use %pK through printk", " - bpf: Use tnums for JEQ/JNE is_branch_taken logic", " - ACPI: video: force native for Lenovo 82K8", " - libbpf: Fix USDT SIB argument handling causing unrecognized register", " error", " - ACPI: resource: Skip IRQ override on ASUS Vivobook Pro N6506CU", " - thermal: gov_step_wise: Allow cooling level to be reduced earlier", " - thermal: intel: selftests: workload_hint: Mask unsupported types", " - cpufreq: ondemand: Update the efficient idle check for Intel extended", " Families", " - pwm: pca9685: Use bulk write to atomicially update registers", " - i3c: mipi-i3c-hci-pci: Add support for Intel Wildcat Lake-U I3C", " - hwmon: (dell-smm) Remove Dell Precision 490 custom config data", " - selftests/bpf: Fix flaky bpf_cookie selftest", " - mfd: core: Increment of_node's refcount before linking it to the", " platform device", " - mfd: intel-lpss: Add Intel Wildcat Lake LPSS PCI IDs", " - drm/amdgpu: add range check for RAS bad page address", " - drm/amdgpu: Check vcn sram load return value", " - ASoC: mediatek: Use SND_JACK_AVOUT for HDMI/DP jacks", " - drm/amd/display: Reset apply_eamless_boot_optimization when dpms_off", " - wifi: rtw89: print just once for unknown C2H events", " - PCI/ERR: Update device error_state already after reset", " - scsi: ufs: host: mediatek: Fix PWM mode switch issue", " - HID: pidff: Use direction fix only for conditional effects", " - HID: pidff: PERMISSIVE_CONTROL quirk autodetection", " - wifi: rtw89: fix BSSID comparison for non-transmitted BSSID", " - dm error: mark as DM_TARGET_PASSES_INTEGRITY", " - bnxt_en: Add Hyper-V VF ID", " - idpf: do not linearize big TSO packets", " - net: wangxun: limit tx_max_coalesced_frames_irq", " - rpmsg: char: Export alias for RPMSG ID rpmsg-raw from table", " - net: ipv4: allow directed broadcast routes to use dst hint", " - scsi: mpi3mr: Fix I/O failures during controller reset", " - drm/amd/display: Support HW cursor 180 rot for any number of pipe splits", " - media: pci: mgb4: Fix timings comparison in VIDIOC_S_DV_TIMINGS", " - ASoC: SOF: ipc4-pcm: Add fixup for channels", " - drm/amdgpu: Avoid vcn v5.0.1 poison irq call trace on sriov guest", " - inet_diag: annotate data-races in inet_diag_bc_sk()", " - scsi: ufs: exynos: fsd: Gate ref_clk and put UFS device in reset on", " suspend", " - drm/xe/guc: Increase GuC crash dump buffer size", " - drm: panel-backlight-quirks: Make EDID match optional", " - PCI: imx6: Enable the Vaux supply if available", " - drm/xe/guc: Set upper limit of H2G retries over CTB", " - crypto: ccp: Skip SEV and SNP INIT for kdump boot", " - drm/amd/display: Fix pbn_div Calculation Error", " - tty/vt: Add missing return value for VT_RESIZE in vt_ioctl()", " - PCI: endpoint: pci-epf-test: Limit PCIe BAR size for fixed BARs", " - selftests: mptcp: join: allow more time to send ADD_ADDR", " - scsi: ufs: host: mediatek: Correct system PM flow", " - selftests: traceroute: Return correct value on failure", " - openrisc: Add R_OR1K_32_PCREL relocation type module support", " - wifi: mt76: mt76_eeprom_override to int", " - wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error", " - drm/amd/display: Set up pixel encoding for YCBCR422", " - drm/amd/display: fix dml ms order of operations", " - scsi: lpfc: Clean up allocated queues when queue setup mbox commands", " fail", " - scsi: lpfc: Decrement ndlp kref after FDISC retries exhausted", " - scsi: lpfc: Ensure PLOGI_ACC is sent prior to PRLI in Point to Point", " topology", " - wifi: rtw89: renew a completion for each H2C command waiting C2H event", " - usb: xhci-pci: add support for hosts with zero USB3 ports", " - RDMA/ipoib: Remove NULL check before dev_{put, hold}", " - IB/ipoib: Ignore L3 master device", " - bus: mhi: core: Improve mhi_sync_power_up handling for SYS_ERR state", " - wifi: mac80211: Track NAN interface start/stop", " - crypto: hisilicon/qm - invalidate queues in use", " - crypto: hisilicon/qm - adjust the internal processing sequence of the vf", " enable and disable", " - crypto: hisilicon/qm - clear all VF configurations in the hardware", " - selftests: forwarding: Reorder (ar)ping arguments to obey POSIX getopt", " - net: dsa: microchip: Set SPI as bus interface during reset for KSZ8463", " - drm/amd/display: Init dispclk from bootup clock for DCN314", " - drm/amd/display: Fix for test crash due to power gating", " - drm/amd/display: change dc stream color settings only in atomic commit", " - ACPI: scan: Update honor list for RPMI System MSI", " - vfio/pci: Fix INTx handling on legacy non-PCI 2.3 devices", " - Bluetooth: btusb: Add new VID/PID 13d3/3633 for MT7922", " - net: stmmac: est: Drop frames causing HLBS error", " - usb: xhci-pci: Fix USB2-only root hub registration", " - drm/amd/display: Add fallback path for YCBCR422", " - RDMA/hns: Fix recv CQ and QP cache affinity", " - clk: clocking-wizard: Fix output clock register offset for Versal", " platforms", " - LoongArch: Handle new atomic instructions for probes", " - net: wwan: t7xx: add support for HP DRMR-H01", " - ceph: fix potential race condition in ceph_ioctl_lazyio()", " - net: ionic: add dma_wmb() before ringing TX doorbell", " - net: ionic: map SKB after pseudo-header checksum prep", " - bnxt_en: Add mem_valid bit to struct bnxt_ctx_mem_type", " - bnxt_en: Refactor bnxt_free_ctx_mem()", " - bnxt_en: Add a 'force' parameter to bnxt_free_ctx_mem()", " - net: wan: framer: pef2256: Switch to devm_mfd_add_devices()", " - drm/amdgpu/smu: Handle S0ix for vangogh", " - drm/amd/display: update color on atomic commit time", " - drm/mediatek: Add pm_runtime support for GCE power control", " - arm64: kprobes: check the return value of set_memory_rox()", " - NFS4: Apply delay_retrans to async operations", " - HID: nintendo: Wait longer for initial probe", " - HID: logitech-hidpp: Add HIDPP_QUIRK_RESET_HI_RES_SCROLL", " - NFSD: Skip close replay processing if XDR encoding fails", " - net: ethernet: ti: am65-cpsw-qos: fix IET verify/response timeout", " - net: ethernet: ti: am65-cpsw-qos: fix IET verify retry mechanism", " - proc: fix the issue of proc_mem_open returning NULL", " - ext4: introduce ITAIL helper", " - LoongArch: KVM: Add delay until timer interrupt injected", " - nfsd: add missing FATTR4_WORD2_CLONE_BLKSIZE from supported attributes", " - ftrace: Fix BPF fexit with livepatch", " - btrfs: zoned: fix conventional zone capacity calculation", " - btrfs: release root after error in data_reloc_print_warning_inode()", " - pmdomain: imx: Fix reference count leak in imx_gpc_remove", " - selftests: mptcp: join: userspace: longer transfer", " - selftests: mptcp: join: properly kill background tasks", " - wifi: cfg80211: add an hrtimer based delayed work item", " - proc: proc_maps_open allow proc_mem_open to return NULL", " - Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_complete", " - Upstream stable to v6.6.117, v6.12.58, v6.12.59", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68204", " - pmdomain: arm: scmi: Fix genpd leak on provider registration failure", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-22107", " - net: dsa: sja1105: fix kasan out-of-bounds warning in", " sja1105_table_delete_entry()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-39981", " - Bluetooth: MGMT: Fix possible UAFs", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-22121", " - ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-23129", " - wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq()", " in error path", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40287", " - exfat: fix improper check of dentry.stream.valid_size", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40289", " - drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68201", " - drm/amdgpu: remove two invalid BUG_ON()s", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68180", " - drm/amd/display: Fix NULL deref in debugfs odm_combine_segments", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68322", " - parisc: Avoid crash due to unaligned access in unwinder", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40305", " - 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40307", " - exfat: validate cluster allocation bits of the allocation bitmap", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68190", " - drm/amdgpu/atom: Check kcalloc() for WS buffer in", " amdgpu_atom_execute_table_locked()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68315", " - f2fs: fix to detect potential corrupted nid in free_nid_list", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40339", " - drm/amdgpu: fix nullptr err of vm_handle_moved", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68311", " - tty: serial: ip22zilog: Use platform device for probing", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68313", " - x86/CPU/AMD: Add RDSEED fix for Zen5", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40360", " - drm/sysfb: Do not dereference NULL pointer in plane reset", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68734", " - isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40272", " - mm/secretmem: fix use-after-free race in fault handler", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40077", " - f2fs: fix to avoid overflow while left shift operation", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68245", " - net: netpoll: fix incorrect refcount handling causing incorrect cleanup", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40293", " - iommufd: Don't overflow during division for dirty tracking", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40303", " - btrfs: ensure no dirty metadata is written back for an fs with errors", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68184", " - drm/mediatek: Disable AFBC support on Mediatek DRM driver", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40268", " - cifs: client: fix memory leak in smb3_fs_context_parse_param", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40269", " - ALSA: usb-audio: Fix potential overflow of PCM transfer buffer", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40271", " - fs/proc: fix uaf in proc_readdir_de()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68241", " - ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68246", " - ksmbd: close accepted socket when per-IP limit rejects connection", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40273", " - NFSD: free copynotify stateid in nfs4_free_ol_stateid()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68208", " - bpf: account for current allocated stack depth in", " widen_imprecise_scalars()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68200", " - bpf: Add bpf_prog_run_data_pointers()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40275", " - ALSA: usb-audio: Fix NULL pointer dereference in", " snd_usb_mixer_controls_badd", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40277", " - drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40278", " - net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-", " infoleak", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40279", " - net: sched: act_connmark: initialize struct tc_ife to fix kernel leak", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40280", " - tipc: Fix use-after-free in tipc_mon_reinit_self().", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40281", " - sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40282", " - Bluetooth: 6lowpan: reset link-local header on ipv6 recv path", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40283", " - Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40284", " - Bluetooth: MGMT: cancel mesh send timer when hdev removed", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40285", " - smb/server: fix possible refcount leak in smb2_sess_setup()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40286", " - smb/server: fix possible memory leak in smb2_read()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40288", " - drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68244", " - drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40292", " - virtio-net: fix received length check in big packets", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40328", " - smb: client: fix potential UAF in smb2_close_cached_fid()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40294", " - Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40329", " - drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68320", " - lan966x: Fix sleeping in atomic context", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68192", " - net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40331", " - sctp: Prevent TOCTOU out-of-bounds write", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40301", " - Bluetooth: hci_event: validate skb length for unknown CC opcode", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40358", " - riscv: stacktrace: Disable KASAN checks for non-current tasks", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40304", " - fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68183", " - ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68173", " - ftrace: Fix softlockup in ftrace_module_enable", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40306", " - orangefs: fix xattr related buffer overflow...", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40308", " - Bluetooth: bcsp: receive data only if registered", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40309", " - Bluetooth: SCO: Fix UAF on sco_conn_free", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40310", " - amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40311", " - accel/habanalabs: support mapping cb with vmalloc-backed coherent memory", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68185", " - nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode", " dereferencing", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68176", " - PCI: cadence: Check for the existence of cdns_pcie::ops before using it", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68168", " - jfs: fix uninitialized waitqueue in transaction manager", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40312", " - jfs: Verify inode mode when loading from disk", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40333", " - f2fs: fix infinite loop in __insert_extent_tree()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68321", " - page_pool: always add GFP_NOWARN for ATOMIC allocations", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68191", " - udp_tunnel: use netdev_warn() instead of netdev_WARN()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40313", " - ntfs3: pretend $Extend records as regular files", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40314", " - usb: cdns3: gadget: Use-after-free during failed initialization and exit", " of cdnsp gadget", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40337", " - net: stmmac: Correctly handle Rx checksum offload errors", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68194", " - media: imon: make send_packet() more robust", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40363", " - net: ipv6: fix field-spanning memcpy warning in AH output", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68178", " - blk-cgroup: fix possible deadlock while configuring policy", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40341", " - futex: Don't leak robust_list pointer on exec race", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40342", " - nvme-fc: use lock accessing port_state and rport state", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40343", " - nvmet-fc: avoid scheduling association deletion twice", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68177", " - cpufreq/longhaul: handle NULL policy in longhaul_exit", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40315", " - usb: gadget: f_fs: Fix epfile null pointer access after ep enable.", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68310", " - s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68179", " - s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40317", " - regmap: slimbus: fix bus_context pointer in regmap init calls", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40318", " - Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68312", " - usbnet: Prevents free active kevent", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68172", " - crypto: aspeed - fix double free caused by devm", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40319", " - bpf: Sync pending IRQ work before freeing ring buffer", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68171", " - x86/fpu: Ensure XFD state on signal delivery", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40320", " - smb: client: fix potential cfid UAF in smb2_query_info_compound", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40321", " - wifi: brcmfmac: fix crash while sending Action Frames in standalone AP", " Mode", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40322", " - fbdev: bitblit: bound-check glyph index in bit_putcs*", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40211", " - ACPI: video: Fix use-after-free in acpi_video_switch_brightness()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40323", " - fbcon: Set fb_display[i]->mode to NULL when the mode is released", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40324", " - NFSD: Fix crash in nfsd4_read_release()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282)", " - exec: Fix incorrect type for ret", " - hfs: clear offset and space out of valid records in b-tree node", " - hfs: make proper initalization of struct hfs_find_data", " - dlm: check for defined force value in dlm_lockspace_release", " - hfsplus: return EIO when type of hidden directory mismatch in", " hfsplus_fill_super()", " - lkdtm: fortify: Fix potential NULL dereference on kmalloc failure", " - m68k: bitops: Fix find_*_bit() signatures", " - powerpc/32: Remove PAGE_KERNEL_TEXT to fix startup failure", " - drivers/perf: hisi: Relax the event ID check in the framework", " - smb: server: let smb_direct_flush_send_list() invalidate a remote key", " first", " - Unbreak 'make tools/*' for user-space targets", " - net/mlx5e: Return 1 instead of 0 in invalid case in", " mlx5e_mpwrq_umr_entry_size()", " - rtnetlink: Allow deleting FDB entries in user namespace", " - net: enetc: correct the value of ENETC_RXB_TRUESIZE", " - dpaa2-eth: fix the pointer passed to PTR_ALIGN on Tx path", " - can: bxcan: bxcan_start_xmit(): use can_dev_dropped_skb() instead of", " can_dropped_invalid_skb()", " - selftests: net: fix server bind failure in sctp_vrf.sh", " - net/mlx5e: Reuse per-RQ XDP buffer to avoid stack zeroing overhead", " - net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for legacy RQ", " - arm64, mm: avoid always making PTE dirty in pte_mkwrite()", " - net: bonding: fix possible peer notify event loss or dup issue", " - dma-debug: don't report false positives with", " DMA_BOUNCE_UNALIGNED_KMALLOC", " - gpio: pci-idio-16: Define maximum valid register address offset", " - gpio: 104-idio-16: Define maximum valid register address offset", " - Revert \"cpuidle: menu: Avoid discarding useful information\"", " - ACPICA: Work around bogus -Wstringop-overread warning since GCC 11", " - can: netlink: can_changelink(): allow disabling of automatic restart", " - cifs: Fix TCP_Server_Info::credits to be signed", " - MIPS: Malta: Fix keyboard resource preventing i8042 driver from", " registering", " - net: stmmac: dwmac-rk: Fix disabling set_clock_selection", " - net: usb: rtl8150: Fix frame padding", " - net: ravb: Enforce descriptor type ordering", " - net: ravb: Ensure memory write completes before ringing TX doorbell", " - selftests: mptcp: join: mark 'flush re-add' as skipped if not supported", " - selftests: mptcp: join: mark implicit tests as skipped if not supported", " - spi: spi-nxp-fspi: add extra delay after dll locked", " - firmware: arm_scmi: Fix premature SCMI_XFER_FLAG_IS_RAW clearing in raw", " mode", " - RISC-V: Define pgprot_dmacoherent() for non-coherent devices", " - RISC-V: Don't print details of CPUs disabled in DT", " - hwmon: (sht3x) Fix error handling", " - gpio: ljca: Fix duplicated IRQ mapping", " - io_uring: correct __must_hold annotation in io_install_fixed_file", " - sched: Remove never used code in mm_cid_get()", " - USB: serial: option: add UNISOC UIS7720", " - USB: serial: option: add Quectel RG255C", " - USB: serial: option: add Telit FN920C04 ECM compositions", " - usb/core/quirks: Add Huawei ME906S to wakeup quirk", " - usb: raw-gadget: do not limit transfer length", " - xhci: dbc: enable back DbC in resume if it was enabled before suspend", " - x86/microcode: Fix Entrysign revision check for Zen1/Naples", " - binder: remove \"invalid inc weak\" check", " - mei: me: add wildcat lake P DID", " - misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup", " - tcpm: switch check for role_sw device with fw_node", " - dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp", " - serial: 8250_dw: handle reset control deassert error", " - serial: 8250_exar: add support for Advantech 2 port card with Device ID", " 0x0018", " - serial: 8250_mtk: Enable baud clock and manage in runtime PM", " - devcoredump: Fix circular locking dependency with devcd->mutex.", " - xfs: always warn about deprecated mount options", " - fuse: allocate ff->release_args only if release is needed", " - audit: record fanotify event regardless of presence of rules", " - perf: Use current->flags & PF_KTHREAD|PF_USER_WORKER instead of", " current->mm == NULL", " - perf: Have get_perf_callchain() return NULL if crosstask and user are", " set", " - perf: Skip user unwind if the task is a kernel thread", " - x86/bugs: Report correct retbleed mitigation status", " - x86/bugs: Fix reporting of LFENCE retpoline", " - EDAC/mc_sysfs: Increase legacy channel support to 16", " - btrfs: zoned: return error from btrfs_zone_finish_endio()", " - btrfs: zoned: refine extent allocator hint selection", " - btrfs: scrub: replace max_t()/min_t() with clamp() in", " scrub_throttle_dev_io()", " - btrfs: always drop log root tree reference in btrfs_replay_log()", " - btrfs: use level argument in log tree walk callback replay_one_buffer()", " - btrfs: use smp_mb__after_atomic() when forcing COW in", " create_pending_snapshot()", " - arch: Add the macro COMPILE_OFFSETS to all the asm-offsets.c", " - mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR", " - selftests: mptcp: disable add_addr retrans in endpoint_tests", " - selftests: mptcp: join: mark 'delete re-add signal' as skipped if not", " supported", " - serial: sc16is7xx: remove useless enable of enhanced features", " - xhci: dbc: poll at different rate depending on data transfer activity", " - xhci: dbc: Allow users to modify DbC poll interval via sysfs", " - xhci: dbc: Improve performance by removing delay in transfer event", " polling.", " - xhci: dbc: Avoid event polling busyloop if pending rx transfers are", " inactive.", " - xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall", " event", " - bits: add comments and newlines to #if, #else and #endif directives", " - bits: introduce fixed-type GENMASK_U*()", " - gpio: regmap: Allow to allocate regmap-irq device", " - gpio: regmap: add the .fixed_direction_output configuration parameter", " - gpio: idio-16: Define fixed direction of the GPIO lines", " - PCI: Test for bit underflow in pcie_set_readrq()", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - s390/mm: Use __GFP_ACCOUNT for user page table allocations", " - ptp: ocp: Fix typo using index 1 instead of i in SMA initialization loop", " - riscv: hwprobe: avoid uninitialized variable use in hwprobe_arch_id()", " - perf/x86/intel: Add ICL_FIXED_0_ADAPTIVE bit into INTEL_FIXED_BITS_MASK", " - cpuset: Use new excpus for nocpu error check when enabling root", " partition", " - btrfs: abort transaction on specific error places when walking log tree", " - btrfs: abort transaction in the process_one_buffer() log tree walk", " callback", " - btrfs: abort transaction if we fail to update inode in log replay dir", " fixup", " - btrfs: tree-checker: add inode extref checks", " - docs: kdoc: handle the obsolescensce of docutils.ErrorString()", " - bonding: return detailed error when loading native XDP fails", " - btrfs: tree-checker: fix bounds check in check_inode_extref()", " - Upstream stable to v6.6.115, v6.6.116, v6.12.56, v6.12.57", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-37860", " - sfc: fix NULL dereferences in ef100_process_design_param()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-21833", " - iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-22105", " - bonding: check xdp prog when set bond mode", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-38643", " - wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-23130", " - f2fs: fix to avoid panic once fallocation fails for pinfile", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40353", " - arm64: mte: Do not warn if the page is already tagged in copy_highpage()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-39678", " - platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40235", " - btrfs: directly free partially initialized fs_info in", " btrfs_check_leaked_roots()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40238", " - net/mlx5: Fix IPsec cleanup over MPV device", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40242", " - gfs2: Fix unlikely race in gdlm_put_lock", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40083", " - net/sched: sch_qfq: Fix null-deref in agg_dequeue", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40084", " - ksmbd: transport_ipc: validate payload size before reading handle", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40220", " - fuse: fix livelock in synchronous file put from fuseblk workers", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40237", " - fs/notify: call exportfs_encode_fid with s_umount", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-68249", " - most: usb: hdm_probe: Fix calling put_device() before device", " initialization", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40223", " - most: usb: Fix use-after-free in hdm_disconnect", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40106", " - comedi: fix divide-by-zero in comedi_buf_munge()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40226", " - firmware: arm_scmi: Account for failed debug initialization", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40231", " - vsock: fix lock inversion in vsock_assign_transport()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40233", " - ocfs2: clear extent cache after moving/defragmenting extents", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40346", " - arch_topology: Fix incorrect error check in", " topology_parse_cpu_capacity()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40240", " - sctp: avoid NULL dereference when chunk data buffer is missing", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40350", " - net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding", " RQ", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40347", " - net: enetc: fix the deadlock of enetc_mdio_lock", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40243", " - hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40351", " - hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40349", " - hfs: validate record offset in hfsplus_bmap_alloc", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40244", " - hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40245", " - nios2: ensure that memblock.current_limit is set when setting pfn limits", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267)", " - r8152: add error handling in rtl8152_driver_init", " - f2fs: fix wrong block mapping for multi-devices", " - jbd2: ensure that all ongoing I/O complete before freeing blocks", " - ext4: wait for ongoing I/O to complete before freeing blocks", " - btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation already", " running", " - btrfs: fix incorrect readahead expansion length", " - can: gs_usb: gs_make_candev(): populate net_device->dev_port", " - can: gs_usb: increase max interface to U8_MAX", " - drm/amdgpu: use atomic functions with memory barriers for vm fault info", " - drm/amd: Check whether secure display TA loaded successfully", " - cpufreq: CPPC: Avoid using CPUFREQ_ETERNAL as transition delay", " - epoll: Remove ep_scan_ready_list() in comments", " - eventpoll: Replace rwlock with spinlock", " - drm/msm/adreno: De-spaghettify the use of memory barriers", " - drm/exynos: exynos7_drm_decon: fix uninitialized crtc reference in", " functions", " - drm/exynos: exynos7_drm_decon: properly clear channels during bind", " - drm/exynos: exynos7_drm_decon: remove ctx->suspended", " - media: nxp: imx8-isi: Drop unused argument to mxc_isi_channel_chain()", " - usb: gadget: Store endpoint pointer in usb_request", " - usb: gadget: Introduce free_usb_request helper", " - HID: multitouch: fix sticky fingers", " - dax: skip read lock assertion for read-only filesystems", " - can: m_can: m_can_plat_remove(): add missing pm_runtime_disable()", " - net: dlink: handle dma_map_single() failure properly", " - doc: fix seg6_flowlabel path", " - r8169: fix packet truncation after S4 resume on RTL8168H/RTL8111H", " - amd-xgbe: Avoid spurious link down messages during interface toggle", " - tcp: fix tcp_tso_should_defer() vs large RTT", " - tg3: prevent use of uninitialized remote_adv and local_adv variables", " - tls: trim encrypted message to match the plaintext on short splice", " - net: tls: wait for async completion on last message", " - tls: wait for async encrypt in case of error during latter iterations of", " sendmsg", " - tls: always set record_type in tls_process_cmsg", " - tls: don't rely on tx_work during send()", " - net: usb: lan78xx: Add error handling to lan78xx_init_mac_address", " - net: usb: lan78xx: fix use of improperly initialized dev->chipid in", " lan78xx_reset", " - nvme-multipath: Skip nr_active increments in RETRY disposition", " - riscv: kprobes: Fix probe address validation", " - drm/bridge: lt9211: Drop check for last nibble of version register", " - ASoC: codecs: Fix gain setting ranges for Renesas IDT821034 codec", " - ASoC: nau8821: Cancel jdet_work before handling jack ejection", " - ASoC: nau8821: Generalize helper to clear IRQ status", " - ASoC: nau8821: Add DMI quirk to bypass jack debounce circuit", " - drm/i915/guc: Skip communication warning on reset in progress", " - drm/amd/powerplay: Fix CIK shutdown temperature", " - drm/rockchip: vop2: use correct destination rectangle height check", " - sched/balancing: Rename newidle_balance() => sched_balance_newidle()", " - sched/fair: Fix pelt lost idle time detection", " - ALSA: firewire: amdtp-stream: fix enum kernel-doc warnings", " - selftests/bpf: make arg_parsing.c more robust to crashes", " - HID: hid-input: only ignore 0 battery events for digitizers", " - HID: multitouch: fix name of Stylus input devices", " - selftests: arg_parsing: Ensure data is flushed to disk before reading.", " - arm64: cputype: Add Neoverse-V3AE definitions", " - arm64: errata: Apply workarounds for Neoverse-V3AE", " - NFSD: Rework encoding and decoding of nfsd4_deviceid", " - NFSD: Minor cleanup in layoutcommit processing", " - xfs: rename the old_crc variable in xlog_recover_process", " - xfs: fix log CRC mismatches between i386 and other architectures", " - PM: runtime: Add new devm functions", " - iio: imu: inv_icm42600: Simplify pm_runtime setup", " - phy: cdns-dphy: Store hs_clk_rate and return it", " - phy: cadence: cdns-dphy: Fix PLL lock and O_CMN_READY polling", " - iio: imu: inv_icm42600: reorganize DMA aligned buffers in structure", " - iio: imu: inv_icm42600: Avoid configuring if already pm_runtime", " suspended", " - quota: remove unneeded return value of register_quota_format", " - phy: cadence: cdns-dphy: Update calibration wait time for startup state", " machine", " - PCI: Add PCI_VDEVICE_SUB helper macro", " - ixgbevf: Add support for Intel(R) E610 device", " - ixgbevf: fix getting link speed data for E610 devices", " - nfsd: decouple the xprtsec policy check from check_nfsd_access()", " - PCI/sysfs: Ensure devices are powered for config reads (part 2)", " - ksmbd: browse interfaces list on FSCTL_QUERY_INTERFACE_INFO IOCTL", " - PCI: j721e: Enable ACSPCIE Refclk if \"ti,syscon-acspcie-proxy-ctrl\"", " exists", " - PCI: j721e: Fix programming sequence of \"strap\" settings", " - perf/core: Fix address filter match with backing files", " - perf/core: Fix MMAP event path names with backing files", " - perf/core: Fix MMAP2 event device with backing files", " - drm/msm/a6xx: Fix PDC sleep sequence", " - can: m_can: m_can_handle_state_errors(): fix CAN state transition to", " Error Active", " - can: m_can: m_can_chip_config(): bring up interface in correct state", " - drm/amdgpu: add ip offset support for cyan skillfish", " - drm/amdgpu: add support for cyan skillfish without IP discovery", " - drm/amdgpu: fix handling of harvesting for ip_discovery firmware", " - nvme/tcp: handle tls partially sent records in write_space()", " - nfsd: Use correct error code when decoding extents", " - nfsd: Drop dprintk in blocklayout xdr functions", " - NFSD: Implement large extent array support in pNFS", " - NFSD: Fix last write offset handling in layoutcommit", " - wifi: rtw89: avoid possible TX wait initialization race", " - xfs: use deferred intent items for reaping crosslinked blocks", " - md/raid0: Handle bio_split() errors", " - md/raid1: Handle bio_split() errors", " - md/raid10: Handle bio_split() errors", " - md: fix mssing blktrace bio split events", " - x86/resctrl: Refactor resctrl_arch_rmid_read()", " - x86/resctrl: Fix miscount of bandwidth event when reactivating", " previously unavailable RMID", " - d_alloc_parallel(): set DCACHE_PAR_LOOKUP earlier", " - dmaengine: Add missing cleanup on module unload", " - Upstream stable to v6.6.114, v6.12.55", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40105", " - vfs: Don't leak disconnected dentries on umount", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40092", " - usb: gadget: f_ncm: Refactor bind path to use __free()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40101", " - btrfs: fix memory leaks when rejecting a non SINGLE data profile without", " an RST", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40166", " - drm/xe/guc: Check GuC running state before deregistering exec queue", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40104", " - ixgbevf: fix mailbox API compatibility by negotiating supported features", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40087", " - NFSD: Define a proc_layoutcommit for the FlexFiles layout type", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40196", " - fs: quota: create dedicated workqueue for quota_release_work", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40088", " - hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40085", " - ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40172", " - accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40176", " - tls: wait for pending async decryptions if tls_strp_msg_hold fails", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40173", " - net/ip6_tunnel: Prevent perpetual tunnel growth", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40095", " - usb: gadget: f_rndis: Refactor bind path to use __free()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40094", " - usb: gadget: f_acm: Refactor bind path to use __free()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40093", " - usb: gadget: f_ecm: Refactor bind path to use __free()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40165", " - media: nxp: imx8-isi: m2m: Fix streaming cleanup on release", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40096", " - drm/sched: Fix potential double free in", " drm_sched_job_add_resv_dependencies", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40099", " - cifs: parse_dfs_referrals: prevent oob on malformed input", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40100", " - btrfs: do not assert we found block group item when creating free space", " tree", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40167", " - ext4: detect invalid INLINE_DATA + EXTENTS flag combination", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40103", " - smb: client: Fix refcount leak for cifs_sb_tlink", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158)", " - fs: always return zero on success from replace_fd()", " - fscontext: do not consume log entries when returning -EMSGSIZE", " - clocksource/drivers/clps711x: Fix resource leaks in error paths", " - iio: frequency: adf4350: Fix ADF4350_REG3_12BIT_CLKDIV_MODE", " - asm-generic/io.h: Skip trace helpers if rwmmio events are disabled", " - perf evsel: Avoid container_of on a NULL leader", " - libperf event: Ensure tracing data is multiple of 8 sized", " - clk: at91: peripheral: fix return value", " - perf util: Fix compression checks returning -1 as bool", " - rtc: x1205: Fix Xicor X1205 vendor prefix", " - rtc: optee: fix memory leak on driver removal", " - perf arm_spe: Correct setting remote access", " - perf arm-spe: Rename the common data source encoding", " - perf arm_spe: Correct memory level for remote access", " - perf session: Fix handling when buffer exceeds 2 GiB", " - perf test: Don't leak workload gopipe in PERF_RECORD_*", " - perf test: Add a test for default perf stat command", " - perf tools: Add fallback for exclude_guest", " - perf evsel: Ensure the fallback message is always written to", " - clk: mediatek: mt8195-infra_ao: Fix parent for infra_ao_hdmi_26m", " - clk: mediatek: clk-mux: Do not pass flags to", " clk_mux_determine_rate_flags()", " - clk: nxp: lpc18xx-cgu: convert from round_rate() to determine_rate()", " - clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver", " - clk: tegra: do not overallocate memory for bpmp clocks", " - ASoC: SOF: ipc4-topology: Correct the minimum host DMA buffer size", " - LoongArch: Remove CONFIG_ACPI_TABLE_UPGRADE in platform_init()", " - LoongArch: Init acpi_gbl_use_global_lock to false", " - net/mlx4: prevent potential use after free in mlx4_en_do_uc_filter()", " - drm/vmwgfx: Fix copy-paste typo in validation", " - tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().", " - net: fsl_pq_mdio: Fix device node reference leak in fsl_pq_mdio_probe", " - tools build: Align warning options with perf", " - perf python: split Clang options when invoking Popen", " - tcp: take care of zero tp->window_clamp in tcp_set_rcvlowat()", " - mailbox: zynqmp-ipi: Remove redundant mbox_controller_unregister() call", " - mailbox: zynqmp-ipi: Remove dev.parent check in zynqmp_ipi_free_mboxes", " - drm/amdgpu: Add additional DCE6 SCL registers", " - drm/amd/display: Add missing DCE6 SCL_HORZ_FILTER_INIT* SRIs", " - drm/amd/display: Properly clear SCL_*_FILTER_CONTROL on DCE6", " - drm/amd/display: Properly disable scaling on DCE6", " - netfilter: nf_tables: drop unused 3rd argument from validate callback", " ops", " - bridge: br_vlan_fill_forward_path_pvid: use br_vlan_group_rcu()", " - smb: client: fix missing timestamp updates after utime(2)", " - tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single", " - gpio: wcd934x: mark the GPIO controller as sleeping", " - bpf: Avoid RCU context warning when unpinning htab with internal structs", " - ACPI: property: Fix buffer properties extraction for subnodes", " - ACPI: TAD: Add missing sysfs_remove_group() for ACPI_TAD_RT", " - ACPI: debug: fix signedness issues in read/write helpers", " - arm64: dts: qcom: msm8916: Add missing MDSS reset", " - arm64: dts: qcom: msm8939: Add missing MDSS reset", " - arm64: dts: qcom: sdm845: Fix slimbam num-channels/ees", " - arm64: dts: ti: k3-am62a-main: Fix main padcfg length", " - ARM: OMAP2+: pm33xx-core: ix device node reference leaks in", " amx3_idle_init", " - dt-bindings: phy: rockchip-inno-csi-dphy: make power-domains non-", " required", " - xen/events: Cleanup find_virq() return codes", " - xen/manage: Fix suspend error path", " - xen/events: Update virq_to_irq on migration", " - firmware: meson_sm: fix device leak at probe", " - media: cx18: Add missing check after DMA map", " - media: i2c: mt9v111: fix incorrect type for ret", " - media: mc: Fix MUST_CONNECT handling for pads with no links", " - media: pci: ivtv: Add missing check after DMA map", " - media: venus: firmware: Use correct reset sequence for IRIS2", " - media: lirc: Fix error handling in lirc_register()", " - drm/rcar-du: dsi: Fix 1/2/3 lane support", " - drm/nouveau: fix bad ret code in nouveau_bo_move_prep", " - blk-crypto: fix missing blktrace bio split events", " - bus: mhi: ep: Fix chained transfer handling in read path", " - bus: mhi: host: Do not use uninitialized 'dev' pointer in", " mhi_init_irq_setup()", " - copy_sighand: Handle architectures where sizeof(unsigned long) <", " sizeof(u64)", " - crypto: aspeed - Fix dma_unmap_sg() direction", " - crypto: atmel - Fix dma_unmap_sg() direction", " - crypto: rockchip - Fix dma_unmap_sg() nents value", " - fbdev: Fix logic error in \"offb\" name match", " - fs/ntfs3: Fix a resource leak bug in wnd_extend()", " - iio: dac: ad5360: use int type to store negative error codes", " - iio: dac: ad5421: use int type to store negative error codes", " - iio: frequency: adf4350: Fix prescaler usage.", " - iio: xilinx-ams: Fix AMS_ALARM_THR_DIRECT_MASK", " - iio: xilinx-ams: Unmask interrupts after updating alarms", " - init: handle bootloader identifier in kernel parameters", " - iio: imu: inv_icm42600: Drop redundant pm_runtime reinitialization in", " resume", " - iommu/vt-d: PRS isn't usable if PDS isn't supported", " - KEYS: trusted_tpm1: Compare HMAC values in constant time", " - lib/genalloc: fix device leak in of_gen_pool_get()", " - of: unittest: Fix device reference count leak in", " of_unittest_pci_node_verify", " - openat2: don't trigger automounts with RESOLVE_NO_XDEV", " - parisc: don't reference obsolete termio struct for TC* constants", " - parisc: Remove spurious if statement from raw_copy_from_user()", " - nvme-pci: Add TUXEDO IBS Gen8 to Samsung sleep quirk", " - pinctrl: samsung: Drop unused S3C24xx driver data", " - power: supply: max77976_charger: fix constant current reporting", " - powerpc/powernv/pci: Fix underflow and leak issue", " - powerpc/pseries/msi: Fix potential underflow and leak issue", " - sched/deadline: Fix race in push_dl_task()", " - scsi: hpsa: Fix potential memory leak in hpsa_big_passthru_ioctl()", " - sparc64: fix hugetlb for sun4u", " - sparc: fix error handling in scan_one_device()", " - mtd: rawnand: fsmc: Default to autodetect buswidth", " - mmc: core: SPI mode remove cmd7", " - memory: samsung: exynos-srom: Fix of_iomap leak in exynos_srom_probe", " - rtc: interface: Ensure alarm irq is enabled when UIE is enabled", " - rtc: interface: Fix long-standing race when setting alarm", " - rseq/selftests: Use weak symbol reference, not definition, to link with", " glibc", " - PCI: tegra: Convert struct tegra_msi mask_lock into raw spinlock", " - PCI/sysfs: Ensure devices are powered for config reads", " - PCI/ERR: Fix uevent on failure to recover", " - PCI/AER: Fix missing uevent on recovery when a reset is requested", " - PCI/AER: Support errors introduced by PCIe r6.0", " - PCI: keystone: Use devm_request_irq() to free \"ks-pcie-error-irq\" on", " exit", " - PCI: rcar-host: Drop PMSR spinlock", " - PCI: rcar-host: Convert struct rcar_msi mask_lock into raw spinlock", " - PCI: tegra194: Fix broken tegra_pcie_ep_raise_msi_irq()", " - PCI: tegra194: Handle errors in BPMP response", " - spi: cadence-quadspi: Flush posted register writes before INDAC access", " - spi: cadence-quadspi: Flush posted register writes before DAC access", " - x86/umip: Check that the instruction opcode is at least two bytes", " - x86/umip: Fix decoding of register forms of 0F 01 (SGDT and SIDT", " aliases)", " - selftests: mptcp: join: validate C-flag + def limit", " - wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again", " - wifi: mt76: mt7921u: Add VID/PID for Netgear A7500", " - mm/page_alloc: only set ALLOC_HIGHATOMIC for __GPF_HIGH allocations", " - mm/hugetlb: early exit from hugetlb_pages_alloc_boot() when", " max_huge_pages=0", " - NFSD: Fix destination buffer size in nfsd4_ssc_setup_dul()", " - nfsd: nfserr_jukebox in nlm_fopen should lead to a retry", " - ext4: increase i_disksize to offset + len in", " ext4_update_disksize_before_punch()", " - ext4: correctly handle queries for metadata mappings", " - ext4: fix an off-by-one issue during moving extents", " - ext4: guard against EA inode refcount underflow in xattr update", " - ext4: validate ea_ino and size in check_xattrs", " - ACPICA: Allow to skip Global Lock initialization", " - ext4: free orphan info with kvfree", " - lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older", " - Squashfs: add additional inode sanity checking", " - media: mc: Clear minor number before put device", " - mfd: intel_soc_pmic_chtdc_ti: Fix invalid regmap-config max_register", " value", " - mfd: intel_soc_pmic_chtdc_ti: Drop unneeded assignment for cache_type", " - mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag", " - ksmbd: add max ip connections parameter", " - misc: fastrpc: Add missing dev_err newlines", " - misc: fastrpc: Save actual DMA size in fastrpc_map structure", " - PCI: endpoint: Remove surplus return statement from", " pci_epf_test_clean_dma_chan()", " - btrfs: fix the incorrect max_bytes value for find_lock_delalloc_range()", " - KVM: SVM: Emulate PERF_CNTR_GLOBAL_STATUS_SET for PerfMonV2", " - ipmi: Fix handling of messages with provided receive message pointer", " - arm64: kprobes: call set_memory_rox() for kprobe page", " - arm64: mte: Do not flag the zero page as PG_mte_tagged", " - ACPI: battery: allocate driver data through devm_ APIs", " - ACPI: battery: initialize mutexes through devm_ APIs", " - ACPI: battery: Check for error code from devm_mutex_init() call", " - ACPI: battery: Add synchronization between interface updates", " - ACPI: property: Disregard references in data-only subnode lists", " - ACPI: property: Add code comments explaining what is going on", " - ACPI: property: Do not pass NULL handles to acpi_attach_data()", " - s390/bpf: Change seen_reg to a mask", " - s390/bpf: Centralize frame offset calculations", " - s390/bpf: Describe the frame using a struct instead of constants", " - s390/bpf: Write back tail call counter for BPF_PSEUDO_CALL", " - s390/bpf: Write back tail call counter for BPF_TRAMP_F_CALL_ORIG", " - selftests/mm: skip soft-dirty tests when CONFIG_MEM_SOFT_DIRTY is", " disabled", " - mptcp: pm: in-kernel: usable client side with C-flag", " - irqchip/sifive-plic: Make use of __assign_bit()", " - irqchip/sifive-plic: Avoid interrupt ID 0 handling during suspend/resume", " - minixfs: Verify inode mode when loading from disk", " - fs: Add 'initramfs_options' to set initramfs mount options", " - cramfs: Verify inode mode when loading from disk", " - writeback: Avoid softlockup when switching many inodes", " - writeback: Avoid excessively long inode switching times", " - perf test stat: Avoid hybrid assumption when virtualized", " - rseq: Protect event mask against membarrier IPI", " - perf vendor events arm64 AmpereOneX: Fix typo - should be", " l1d_cache_access_prefetches", " - ASoC: SOF: ipc4-topology: Account for different ChainDMA host buffer", " size", " - ASoC: SOF: Intel: hda-pcm: Place the constraint on period time instead", " of buffer time", " - ASoC: SOF: Intel: Read the LLP via the associated Link DMA channel", " - s390/cio: Update purge function to unregister the unused subchannels", " - mailbox: mtk-cmdq-mailbox: Switch to __pm_runtime_put_autosuspend()", " - mailbox: mtk-cmdq: Switch to pm_runtime_put_autosuspend()", " - mailbox: mtk-cmdq: Remove pm_runtime APIs from cmdq_mbox_send_data()", " - cifs: Fix copy_to_iter return value check", " - ARM: AM33xx: Implement TI advisory 1.0.36 (EMU0/EMU1 pins state on", " reset)", " - media: s5p-mfc: remove an unused/uninitialized variable", " - media: ti: j721e-csi2rx: Use devm_of_platform_populate", " - media: ti: j721e-csi2rx: Fix source subdev link creation", " - drm/xe/uapi: loosen used tracking restriction", " - PCI: xilinx-nwl: Fix ECAM programming", " - PCI: tegra194: Reset BARs when running in PCIe endpoint mode", " - s390: Add -Wno-pointer-sign to KBUILD_CFLAGS_DECOMPRESSOR", " - wifi: mt76: mt7925u: Add VID/PID for Netgear A9000", " - ext4: add ext4_sb_bread_nofail() helper function for", " ext4_free_branches()", " - mm/ksm: fix incorrect KSM counter handling in mm_struct during fork", " - KVM: x86: Advertise SRSO_USER_KERNEL_NO to userspace", " - copy_file_range: limit size if in compat mode", " - Upstream stable to v6.6.113, v6.12.54", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40198", " - ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40159", " - xsk: Harden userspace-supplied xdp_desc validation", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40221", " - media: pci: mg4b: fix uninitialized iio scan data", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40180", " - mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40178", " - pid: Add a judgment for ns null in pid_nr_ns", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40202", " - ipmi: Rework user message limit handling", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40032", " - PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before", " release", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40038", " - KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40042", " - tracing: Fix race condition in kprobe initialization causing NULL", " pointer dereference", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40200", " - Squashfs: reject negative file sizes in squashfs_read_inode()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40179", " - ext4: verify orphan file size is not too big", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40218", " - mm/damon/vaddr: do not repeat pte_offset_map_lock() until success", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40219", " - PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40193", " - xtensa: simdisk: add input size check in proc_write_simdisk", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40204", " - sctp: Fix MAC comparison to be constant-time", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40192", " - Revert \"ipmi: fix msg stack when IPMI is disconnected\"", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40188", " - pwm: berlin: Fix wrong register in suspend/resume", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40201", " - kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in", " sys_prlimit64() paths", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40194", " - cpufreq: intel_pstate: Fix object lifecycle issue in", " update_qos_request()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40205", " - btrfs: avoid potential out-of-bounds in btrfs_encode_fh()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40160", " - xen/events: Return -EEXIST for bound VIRQs", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40206", " - netfilter: nft_objref: validate objref and objrefmap expressions", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40183", " - bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40187", " - net/sctp: fix a null dereference in sctp_disposition", " sctp_sf_do_5_1D_ce()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40111", " - drm/vmwgfx: Fix Use-after-free in validation", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40110", " - drm/vmwgfx: Fix a null-ptr access in the cursor snooper", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40001", " - scsi: mvsas: Fix use-after-free bugs in mvs_work_queue", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40207", " - media: v4l2-subdev: Fix alloc failure check in", " v4l2_subdev_call_state_try()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072)", " - media: tunner: xc5000: Refactor firmware load", " - USB: serial: option: add SIMCom 8230C compositions", " - wifi: rtlwifi: rtl8192cu: Don't claim USB ID 07b8:8188", " - ASoC: amd: acp: Adjust pdm gain value", " - dm-integrity: limit MAX_TAG_SIZE to 255", " - platform/x86/amd/pmc: Add MECHREVO Yilong15Pro to spurious_8042 list", " - perf subcmd: avoid crash in exclude_cmds when excludes is empty", " - ASoC: rt5682s: Adjust SAR ADC button mode to fix noise issue", " - btrfs: ref-verify: handle damaged extent root tree", " - can: rcar_canfd: Fix controller mode setting", " - platform/x86/amd/pmc: Add Stellaris Slim Gen6 AMD to spurious 8042", " quirks list", " - ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free", " - hid: fix I2C read buffer overflow in raw_event() for mcp2221", " - serial: stm32: allow selecting console when the driver is module", " - [Config] enable SERIAL_STM32_CONSOLE", " - staging: axis-fifo: fix maximum TX packet length check", " - staging: axis-fifo: fix TX handling on copy_from_user() failure", " - staging: axis-fifo: flush RX FIFO on read errors", " - driver core/PM: Set power.no_callbacks along with power.no_pm", " - riscv: mm: Use hint address in mmap if available", " - riscv: mm: Do not restrict mmap address based on hint", " - filelock: add FL_RECLAIM to show_fl_flags() macro", " - init: INITRAMFS_PRESERVE_MTIME should depend on BLK_DEV_INITRD", " - seccomp: Fix a race with WAIT_KILLABLE_RECV if the tracer replies too", " fast", " - selftests: arm64: Check fread return value in exec_target", " - gfs2: Fix GLF_INVALIDATE_IN_PROGRESS flag clearing in do_xmote", " - coresight: trbe: Prevent overflow in PERF_IDX2OFF()", " - perf: arm_spe: Prevent overflow in PERF_IDX2OFF()", " - smb: server: fix IRD/ORD negotiation with the client", " - x86/vdso: Fix output operand size of RDPID", " - arm64: dts: renesas: rzg2lc-smarc: Disable CAN-FD channel0", " - regmap: Remove superfluous check for !config in __regmap_init()", " - bpf/selftests: Fix test_tcpnotify_user", " - bpf: Remove migrate_disable in kprobe_multi_link_prog_run", " - libbpf: Fix reuse of DEVMAP", " - ARM: dts: renesas: porter: Fix CAN pin group", " - leds: flash: leds-qcom-flash: Update torch current clamp setting", " - cpufreq: scmi: Account for malformed DT in scmi_dev_used_by_cpus()", " - ACPI: processor: idle: Fix memory leak when register cpuidle device", " failed", " - soc: qcom: rpmh-rsc: Unconditionally clear _TRIGGER bit for TCS", " - pinctrl: meson-gxl: add missing i2c_d pinmux", " - blk-mq: check kobject state_in_sysfs before deleting in", " blk_mq_unregister_hctx", " - ARM: at91: pm: fix MCKx restore routine", " - arm64: dts: apple: t8103-j457: Fix PCIe ethernet iommu-map", " - regulator: scmi: Use int type to store negative error codes", " - selftests/nolibc: fix EXPECT_NZ macro", " - block: use int to store blk_stack_limits() return value", " - PM: sleep: core: Clear power.must_resume in noirq suspend error path", " - ARM: dts: ti: omap: am335x-baltos: Fix ti,en-ck32k-xtal property in DTS", " to use correct boolean syntax", " - ARM: dts: ti: omap: omap3-devkit8000-lcd: Fix ti,keep-vref-on property", " to use correct boolean syntax in DTS", " - ARM: dts: omap: am335x-cm-t335: Remove unused mcasp num-serializer", " property", " - PM / devfreq: mtk-cci: Fix potential error pointer dereference in", " probe()", " - power: supply: cw2015: Fix a alignment coding style issue", " - pinctrl: renesas: Use int type to store negative error codes", " - null_blk: Fix the description of the cache_size module argument", " - arm64: dts: mediatek: mt8195: Remove suspend-breaking reset from pcie0", " - nbd: restrict sockets to TCP and UDP", " - firmware: firmware: meson-sm: fix compile-test default", " - cpuidle: qcom-spm: fix device and OF node leaks at probe", " - arm64: dts: mediatek: mt6331: Fix pmic, regulators, rtc, keys node names", " - arm64: dts: mediatek: mt6795-xperia-m5: Fix mmc0 latch-ck value", " - arm64: dts: mediatek: mt8516-pumpkin: Fix machine compatible", " - pwm: tiehrpwm: Fix corner case in clock divisor calculation", " - ACPICA: Fix largest possible resource descriptor index", " - nvmet-fc: move lsop put work to nvmet_fc_ls_req_op", " - i3c: master: svc: Use manual response for IBI events", " - i3c: master: svc: Recycle unused IBI slot", " - selftests: watchdog: skip ping loop if WDIOF_KEEPALIVEPING not supported", " - bpf: Explicitly check accesses to bpf_sock_addr", " - smp: Fix up and expand the smp_call_function_many() kerneldoc", " - tools/nolibc: make time_t robust if __kernel_old_time_t is missing in", " host headers", " - once: fix race by moving DO_ONCE to separate section", " - hwmon: (mlxreg-fan) Separate methods of fan setting coming from", " different subsystems", " - thermal/drivers/qcom: Make LMH select QCOM_SCM", " - thermal/drivers/qcom/lmh: Add missing IRQ includes", " - i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD", " - i2c: designware: Fix clock issue when PM is disabled", " - i2c: designware: Add disabling clocks when probe fails", " - bpf: Enforce expected_attach_type for tailcall compatibility", " - drm/panel: novatek-nt35560: Fix invalid return value", " - drm/radeon/r600_cs: clean up of dead code in r600_cs", " - f2fs: fix condition in __allow_reserved_blocks()", " - drm/bridge: it6505: select REGMAP_I2C", " - media: zoran: Remove zoran_fh structure", " - phy: rockchip: naneng-combphy: Enable U3 OTG port for RK3568", " - usb: host: max3421-hcd: Fix error pointer dereference in probe cleanup", " - usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure calls", " - serial: max310x: Add error checking in probe()", " - drm/amd/display: Remove redundant semicolons", " - crypto: keembay - Add missing check after sg_nents_for_len()", " - hwrng: nomadik - add ARM_AMBA dependency", " - scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod", " - scsi: myrs: Fix dma_alloc_coherent() error check", " - media: rj54n1cb0c: Fix memleak in rj54n1_probe()", " - RDMA/mlx5: Fix vport loopback forcing for MPV device", " - ALSA: lx_core: use int type to store negative error codes", " - media: st-delta: avoid excessive stack usage", " - crypto: hisilicon/zip - remove unnecessary validation for high-", " performance mode configurations", " - crypto: hisilicon - re-enable address prefetch after device resuming", " - crypto: hisilicon/qm - check whether the input function and PF are on", " the same device", " - inet: ping: check sock_net() in ping_get_port() and ping_lookup()", " - coresight: Only register perf symlink for sinks with alloc_buffer", " - drm/amdgpu: Power up UVD 3 for FW validation (v2)", " - drm/amd/pm: Disable ULV even if unsupported (v3)", " - drm/amd/pm: Fix si_upload_smc_data (v3)", " - drm/amd/pm: Adjust si_upload_smc_data register programming (v3)", " - drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3)", " - drm/amd/pm: Disable MCLK switching with non-DC at 120 Hz+ (v2)", " - drm/amd/pm: Disable SCLK switching on Oland with high pixel clocks (v3)", " - wifi: mwifiex: send world regulatory domain to driver", " - PCI: tegra: Fix devm_kcalloc() argument order for port->phys allocation", " - tcp: fix __tcp_close() to only send RST when required", " - drm/amdkfd: Fix error code sign for EINVAL in svm_ioctl()", " - usb: phy: twl6030: Fix incorrect type for ret", " - usb: gadget: configfs: Correctly set use_os_string at bind", " - tty: n_gsm: Don't block input queue by waiting MSC", " - misc: genwqe: Fix incorrect cmd field being reported in error", " - pps: fix warning in pps_register_cdev when register device fail", " - ASoC: Intel: bytcht_es8316: Fix invalid quirk input mapping", " - ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping", " - ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping", " - drm/msm/dpu: fix incorrect type for ret", " - fs: ntfs3: Fix integer overflow in run_unpack()", " - fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist", " - iio: consumers: Fix handling of negative channel scale in", " iio_convert_raw_to_processed()", " - iio: consumers: Fix offset handling in iio_convert_raw_to_processed()", " - netfilter: ipset: Remove unused htable_bits in macro ahash_region", " - ipvs: Use READ_ONCE/WRITE_ONCE for ipvs->enable", " - watchdog: mpc8xxx_wdt: Reload the watchdog timer when enabling the", " watchdog", " - drivers/base/node: handle error properly in register_one_node()", " - RDMA/cm: Rate limit destroy CM ID timeout error message", " - wifi: mt76: fix potential memory leak in mt76_wmac_probe()", " - f2fs: fix to update map->m_next_extent correctly in f2fs_map_blocks()", " - f2fs: fix to truncate first page in error path of f2fs_truncate()", " - f2fs: fix to mitigate overhead of f2fs_zero_post_eof_page()", " - ACPI: NFIT: Fix incorrect ndr_desc being reportedin dev_err message", " - scsi: qla2xxx: edif: Fix incorrect sign of error code", " - scsi: qla2xxx: Fix incorrect sign of error code in START_SP_W_RETRIES()", " - scsi: qla2xxx: Fix incorrect sign of error code in qla_nvme_xmt_ls_rsp()", " - f2fs: fix zero-sized extent for precache extents", " - RDMA/core: Resolve MAC of next-hop device without ARP support", " - IB/sa: Fix sa_local_svc_timeout_ms read race", " - Documentation: trace: historgram-design: Separate sched_waking histogram", " section heading and the following diagram", " - wifi: mac80211: fix Rx packet handling when pubsta information is not", " available", " - sparc: fix accurate exception reporting in copy_{from_to}_user for", " UltraSPARC", " - sparc: fix accurate exception reporting in copy_{from_to}_user for", " UltraSPARC III", " - sparc: fix accurate exception reporting in copy_{from_to}_user for", " Niagara", " - sparc: fix accurate exception reporting in copy_to_user for Niagara 4", " - sparc: fix accurate exception reporting in copy_{from,to}_user for M7", " - vfio/pds: replace bitmap_free with vfree", " - crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs", " - RDMA/rxe: Fix race in do_task() when draining", " - wifi: rtw89: avoid circular locking dependency in ser_state_run()", " - PCI: tegra194: Fix duplicate PLL disable in", " pex_ep_event_pex_rst_assert()", " - remoteproc: qcom: q6v5: Avoid disabling handover IRQ twice", " - coresight-etm4x: Conditionally access register TRCEXTINSELR", " - coresight: etm4x: Support atclk", " - coresight: trbe: Return NULL pointer for allocation failures", " - NFSv4.1: fix backchannel max_resp_sz verification check", " - scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()", " - usb: vhci-hcd: Prevent suspending virtually attached devices", " - RDMA/siw: Always report immediate post SQ errors", " - net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast", " - vhost: vringh: Fix copy_to_iter return value check", " - Bluetooth: MGMT: Fix not exposing debug UUID on", " MGMT_OP_READ_EXP_FEATURES_INFO", " - Bluetooth: ISO: Fix possible UAF on iso_conn_free", " - Bluetooth: ISO: don't leak skb in ISO_CONT RX", " - Bluetooth: hci_sync: Fix using random address for BIG/PA advertisements", " - KEYS: X.509: Fix Basic Constraints CA flag parsing", " - hwrng: ks-sa - fix division by zero in ks_sa_rng_init", " - ocfs2: fix double free in user_cluster_connect()", " - drivers/base/node: fix double free in register_one_node()", " - mtd: rawnand: atmel: Fix error handling path in", " atmel_nand_controller_add_nands", " - nfp: fix RSS hash key size when RSS is not supported", " - net: ena: return 0 in ena_get_rxfh_key_size() when RSS hash key is not", " configurable", " - net: dlink: handle copy_thresh allocation failure", " - net/mlx5: Stop polling for command response if interface goes down", " - net/mlx5: pagealloc: Fix reclaim race during command interface teardown", " - net/mlx5: fw reset, add reset timeout work", " - smb: client: fix crypto buffers in non-linear memory", " - vhost: vringh: Modify the return value check", " - bpf: Reject negative offsets for ALU ops", " - Squashfs: fix uninit-value in squashfs_get_parent", " - uio_hv_generic: Let userspace take care of interrupt mask", " - ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()", " - ASoC: SOF: ipc3-topology: Fix multi-core and static pipelines tear down", " - fs: udf: fix OOB read in lengthAllocDescs handling", " - net: nfc: nci: Add parameter validation for packet data", " - mfd: rz-mtu3: Fix MTU5 NFCR register offset", " - mfd: vexpress-sysreg: Check the return value of devm_gpiochip_add_data()", " - dm: fix queue start/stop imbalance under suspend/load/resume races", " - dm: fix NULL pointer dereference in __dm_suspend()", " - LoongArch: Automatically disable kaslr if boot from kexec_file", " - ksmbd: fix error code overwriting in smb2_get_info_filesystem()", " - ext4: fix checks for orphan inodes", " - mm: hugetlb: avoid soft lockup when mprotect to large memory area", " - nvdimm: ndtest: Return -ENOMEM if devm_kcalloc() fails in ndtest_probe()", " - misc: fastrpc: Fix fastrpc_map_lookup operation", " - misc: fastrpc: fix possible map leak in fastrpc_put_args", " - misc: fastrpc: Skip reference for DMA handles", " - Input: atmel_mxt_ts - allow reset GPIO to sleep", " - Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info", " leak", " - sunrpc: fix null pointer dereference on zero-length checksum", " - remoteproc: pru: Fix potential NULL pointer dereference in", " pru_rproc_set_ctable()", " - pinctrl: check the return value of pinmux_ops::get_function_name()", " - bus: fsl-mc: Check return value of platform_get_resource()", " - net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock", " - usb: typec: tipd: Clear interrupts first", " - arm64: dts: qcom: qcm2290: Disable USB SS bus instances in park mode", " - usb: cdns3: cdnsp-pci: remove redundant pci_disable_device() call", " - Bluetooth: btusb: Add USB ID 2001:332a for D-Link AX9U rev. A1", " - wifi: rtl8xxxu: Don't claim USB ID 07b8:8188", " - netfs: Prevent duplicate unlocking", " - nvmem: layouts: fix automatic module loading", " - uprobes: uprobe_warn should use passed task", " - lsm: CONFIG_LSM can depend on CONFIG_SECURITY", " - vdso: Add struct __kernel_old_timeval forward declaration to gettime.h", " - selftests: vDSO: vdso_test_abi: Correctly skip whole test with missing", " vDSO", " - PM / devfreq: rockchip-dfi: double count on RK3588", " - soc: mediatek: mtk-svs: fix device leaks on mt8183 probe failure", " - soc: mediatek: mtk-svs: fix device leaks on mt8192 probe failure", " - pwm: tiehrpwm: Don't drop runtime PM reference in .free()", " - pwm: tiehrpwm: Make code comment in .free() more useful", " - pwm: tiehrpwm: Fix various off-by-one errors in duty-cycle calculation", " - spi: fix return code when spi device has too many chipselects", " - bpf: Mark kfuncs as __noclone", " - crypto: octeontx2 - Call strscpy() with correct size argument", " - RDMA/mlx5: Better estimate max_qp_wr to reflect WQE count", " - idpf: fix Rx descriptor ready check barrier in splitq", " - wifi: mt76: mt7996: Fix RX packets configuration for primary WED device", " - wifi: mt76: mt7996: Convert mt7996_wed_rro_addr to LE", " - HID: hidraw: tighten ioctl command parsing", " - wifi: ath12k: fix wrong logging ID used for CE", " - coresight: tmc: Move ACPI support from AMBA driver to platform driver", " - coresight: tmc: Support atclk", " - coresight: catu: Move ACPI support from AMBA driver to platform driver", " - coresight: catu: Support atclk", " - PCI: rcar-gen4: Add missing 1ms delay after PWR reset assertion", " - PCI: rcar-gen4: Assure reset occurs before DBI access", " - Bluetooth: ISO: free rx_skb if not consumed", " - PCI: j721e: Fix incorrect error message in probe()", " - Upstream stable to v6.6.111, v6.6.112, v6.12.52, v6.12.53", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40031", " - tee: fix register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40037", " - fbdev: simplefb: Fix use after free in simplefb_detach_genpds()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40047", " - io_uring/waitid: always prune wait queue entry in io_waitid_wait()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40057", " - ptp: Add a upper bound on max_vclocks", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40058", " - iommu/vt-d: Disallow dirty tracking if incoherent page walk", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40059", " - coresight: Fix incorrect handling for return value of devm_kzalloc", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40155", " - iommu/vt-d: debugfs: Fix legacy mode page table dump logic", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40079", " - riscv, bpf: Sign extend struct ops return values properly", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40000", " - wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40026", " - KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40027", " - net/9p: fix double req put in p9_fd_cancelled", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40109", " - crypto: rng - Ensure set_ent is always present", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-38105", " - ALSA: usb-audio: Kill timer properly at removal", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40107", " - can: hi311x: fix null pointer dereference when resuming from sleep", " before interface was enabled", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-39995", " - media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in", " probe", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-39994", " - media: tuner: xc5000: Fix use-after-free in xc5000_release", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938)", " - scsi: ufs: mcq: Fix memory allocation checks for SQE and CQE", " - firewire: core: fix overlooked update of subsystem ABI version", " - ALSA: usb-audio: Fix block comments in mixer_quirks", " - ALSA: usb-audio: Drop unnecessary parentheses in mixer_quirks", " - ALSA: usb-audio: Avoid multiple assignments in mixer_quirks", " - ALSA: usb-audio: Simplify NULL comparison in mixer_quirks", " - ALSA: usb-audio: Remove unneeded wmb() in mixer_quirks", " - ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5", " - ALSA: usb-audio: Convert comma to semicolon", " - ALSA: usb-audio: Fix build with CONFIG_INPUT=n", " - usb: core: Add 0x prefix to quirks debug output", " - mmc: sdhci-cadence: add Mobileye eyeQ support", " - i2c: designware: Add quirk for Intel Xe", " - ALSA: usb-audio: Add DSD support for Comtrue USB Audio device", " - ALSA: usb-audio: move mixer_quirks' min_mute into common quirk", " - ALSA: usb-audio: Add mute TLV for playback volumes on more devices", " - IB/mlx5: Fix obj_type mismatch for SRQ event subscriptions", " - mm: add folio_expected_ref_count() for reference count calculation", " - mm/gup: check ref_count instead of lru before migration", " - mm/gup: local lru_add_drain() to avoid lru_add_drain_all()", " - mm: folio_may_be_lru_cached() unless folio_test_large()", " - arm64: dts: imx8mp: Correct thermal sensor index", " - ARM: dts: kirkwood: Fix sound DAI cells for OpenRD clients", " - cpufreq: Initialize cpufreq-based invariance before subsys", " - smb: server: don't use delayed_work for post_recv_credits_work", " - wifi: virt_wifi: Fix page fault on connect", " - can: rcar_can: rcar_can_resume(): fix s2ram with PSCI", " - bpf: Reject bpf_timer for PREEMPT_RT", " - xfrm: xfrm_alloc_spi shouldn't use 0 as SPI", " - ethernet: rvu-af: Remove slash from the driver name", " - Bluetooth: hci_sync: Fix hci_resume_advertising_sync", " - bnxt_en: correct offset handling for IPv6 destination address", " - net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS", " - selftests: fib_nexthops: Fix creation of non-FDB nexthops", " - net: dsa: lantiq_gswip: do also enable or disable cpu port", " - net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to", " port_setup()", " - net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB entries", " added to the CPU port", " - HID: asus: add support for missing PX series fn keys", " - i40e: add mask to apply valid bits for itr_idx", " - i40e: improve VF MAC filters accounting", " - ARM: dts: socfpga: sodia: Fix mdio bus probe and PHY address", " - fbcon: Fix OOB access in font allocation", " - s390/cpum_cf: Fix uninitialized warning after backport of ce971233242b", " - ARM: bcm: Select ARM_GIC_V3 for ARCH_BRCMSTB", " - gpiolib: Extend software-node support to support secondary software-", " nodes", " - drm/ast: Use msleep instead of mdelay for edid read", " - minmax: make generic MIN() and MAX() macros available everywhere", " - minmax: simplify min()/max()/clamp() implementation", " - minmax: don't use max() in situations that want a C constant expression", " - minmax: improve macro expansion and type checking", " - minmax: fix up min3() and max3() too", " - minmax.h: add whitespace around operators and after commas", " - minmax.h: update some comments", " - minmax.h: reduce the #define expansion of min(), max() and clamp()", " - minmax.h: move all the clamp() definitions after the min/max() ones", " - minmax.h: simplify the variants of clamp()", " - minmax.h: remove some #defines that are only expanded once", " - drm/i915/backlight: Return immediately when scale() finds invalid", " parameters", " - ALSA: usb-audio: Fix code alignment in mixer_quirks", " - ALSA: hda/realtek: Add support for ASUS NUC using CS35L41 HDA", " - net: fec: rename struct fec_devinfo fec_imx6x_info -> fec_imx6sx_info", " - net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick", " - net: sfp: add quirk for FLYPRO copper SFP+ module", " - HID: amd_sfh: Add sync across amd sfh work functions", " - platform/x86: lg-laptop: Fix WMAB call in fan_mode_store()", " - crypto: sha256 - fix crash at kexec", " - gcc-plugins: Remove TODO_verify_il for GCC >= 16", " - Upstream stable to v6.6.109, v6.6.110, v6.12.50, v6.12.51", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39991", " - wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39992", " - mm: swap: check for stable address space before operating on the VMA", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40013", " - ASoC: qcom: audioreach: fix potential null pointer dereference", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40016", " - media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39996", " - media: b2c2: Fix use-after-free causing by irq_check_work in", " flexcop_pci_remove", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39998", " - scsi: target: target_core_configfs: Add length check to avoid buffer", " overflow", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40009", " - fs/proc/task_mmu: check p->vec_buf for NULL", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39973", " - i40e: add validation for ring_len param", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-38709", " - loop: Avoid updating block size under exclusive owner", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39967", " - fbcon: fix integer overflow in fbcon_do_set_font", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40006", " - mm/hugetlb: fix folio is still mapped when deleted", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40008", " - kmsan: fix out-of-bounds access to shadow memory", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40010", " - afs: Fix potential null pointer dereference in afs_put_server", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40021", " - tracing: dynevent: Add a missing lockdown check on dynevent", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39968", " - i40e: add max boundary check for VF filters", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39969", " - i40e: fix validation of VF state in get resources", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39970", " - i40e: fix input validation logic for action_meta", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39971", " - i40e: fix idx validation in config queues msg", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39972", " - i40e: fix idx validation in i40e_validate_queue_map", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39977", " - futex: Prevent use-after-free during requeue-PI", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40011", " - drm/gma500: Fix null dereference in hdmi teardown", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39978", " - octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39980", " - nexthop: Forbid FDB status change while nexthop is in a group", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40024", " - vhost: Take a reference on the task in struct vhost_task.", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39982", " - Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40020", " - can: peak_usb: fix shift-out-of-bounds issue", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39985", " - can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39986", " - can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39987", " - can: hi311x: populate ndo_change_mtu() to prevent buffer overflow", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39988", " - can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867)", " - ALSA: firewire-motu: drop EPOLLOUT from poll return values as write is", " not supported", " - wifi: mac80211: fix incorrect type for ret", " - pcmcia: omap_cf: Mark driver struct with __refdata to prevent section", " mismatch", " - bonding: set random address only when slaves already exist", " - power: supply: bq27xxx: fix error return in case of no bq27000 hdq", " battery", " - power: supply: bq27xxx: restrict no-battery detection to bq27000", " - LoongArch: Update help info of ARCH_STRICT_ALIGN", " - LoongArch: Align ACPI structures if ARCH_STRICT_ALIGN enabled", " - LoongArch: Check the return value when creating kobj", " - iommu/vt-d: Fix __domain_mapping()'s usage of switch_to_super_page()", " - btrfs: tree-checker: fix the incorrect inode ref size check", " - ASoC: qcom: audioreach: Fix lpaif_type configuration for the I2S", " interface", " - ASoC: qcom: q6apm-lpass-dais: Fix missing set_fmt DAI op for I2S", " - rds: ib: Increment i_fastreg_wrs before bailing out", " - selftests: mptcp: connect: catch IO errors on listen side", " - selftests: mptcp: avoid spurious errors on TCP disconnect", " - ALSA: hda/realtek: Fix mute led for HP Laptop 15-dw4xx", " - io_uring: backport io_should_terminate_tw()", " - io_uring: include dying ring in task_work \"should cancel\" state", " - ASoC: wm8940: Correct PLL rate rounding", " - ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in error", " message", " - drm: bridge: cdns-mhdp8546: Fix missing mutex unlock on error path", " - selftests: mptcp: userspace pm: validate deny-join-id0 flag", " - xhci: dbc: decouple endpoint allocation from initialization", " - xhci: dbc: Fix full DbC transfer ring after several reconnects", " - rtc: pcf2127: fix SPI command byte for PCF2131 backport", " - mptcp: propagate shutdown to subflows when possible", " - minmax: avoid overly complicated constant expressions in VM code", " - minmax: simplify and clarify min_t()/max_t() implementation", " - minmax: add a few more MIN_T/MAX_T users", " - nvme: fix PI insert on write", " - btrfs: fix invalid extref key setup when replaying dentry", " - dpaa2-switch: fix buffer pool seeding for control traffic", " - mptcp: set remote_deny_join_id0 on SYN recv", " - mptcp: tfo: record 'deny join id0' info", " - selftests: mptcp: sockopt: fix error messages", " - net: natsemi: fix `rx_dropped` double accounting on `netif_rx()` failure", " - ice: store max_frame and rx_buf_len only in ice_rx_ring", " - i40e: remove redundant memory barrier when cleaning Tx descs", " - bonding: don't set oif to bond dev when getting NS target destination", " - octeon_ep: fix VF MAC address lifecycle handling", " - net: liquidio: fix overflow in octeon_init_instr_queue()", " - nilfs2: fix CFI failure when accessing /sys/fs/nilfs2/features/*", " - dm-raid: don't set io_min and io_opt for raid1", " - mm: revert \"mm: vmscan.c: fix OOM on swap stress test\"", " - mmc: mvsdio: Fix dma_unmap_sg() nents value", " - KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active", " - ASoC: wm8940: Correct typo in control name", " - ASoC: wm8974: Correct PLL rate rounding", " - ASoC: Intel: catpt: Expose correct bit depth to userspace", " - drm/xe: Fix a NULL vs IS_ERR() in xe_vm_add_compute_exec_queue()", " - smb: client: fix filename matching of deferred files", " - platform/x86: asus-wmi: Fix ROG button mapping, tablet mode on ASUS ROG", " Z13", " - platform/x86: asus-wmi: Re-add extra keys to ignore_key_wlan quirk", " - x86/bugs: Add SRSO_USER_KERNEL_NO support", " - x86/bugs: KVM: Add support for SRSO_MSR_FIX", " - KVM: SVM: Set/clear SRSO's BP_SPEC_REDUCE on 0 <=> 1 VM count", " transitions", " - mptcp: pm: nl: announce deny-join-id0 flag", " - Upstream stable to v6.6.108, v6.12.49", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39932", " - smb: client: let smbd_destroy() call", " disable_work_sync(&info->post_send_credits_work)", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39940", " - dm-stripe: fix a possible integer overflow", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39948", " - ice: fix Rx page leak on multi-buffer frames", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39950", " - net/tcp: Fix a NULL pointer dereference when using TCP-AO with", " TCP_REPAIR", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39961", " - iommu/amd/pgtbl: Fix possible race while increase page table level", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-22106", " - vmxnet3: unregister xdp rxq info in the reset path", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39929", " - smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39931", " - crypto: af_alg - Set merge to zero early in af_alg_sendmsg", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39934", " - drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39937", " - net: rfkill: gpio: Fix crash due to dereferencering uninitialized", " pointer", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39938", " - ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source", " graph failed", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39942", " - ksmbd: smbdirect: verify remaining_data_length respects", " max_fragmented_recv_size", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39943", " - ksmbd: smbdirect: validate data_offset and data_length field of", " smb_direct_data_transfer", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39944", " - octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39945", " - cnic: Fix use-after-free bugs in cnic_delete_task", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39955", " - tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39947", " - net/mlx5e: Harden uplink netdev access against device unbind", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39949", " - qed: Don't collect too many protection override GRC elements", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39951", " - um: virtio_uml: Fix use-after-free after put_device in probe", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39953", " - cgroup: split cgroup_destroy_wq into 3 workqueues", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39957", " - wifi: mac80211: increase scan_ies_len for S1G", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39952", " - wifi: wilc1000: avoid buffer overflow in WID string configuration", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681)", " - mm: introduce and use {pgd,p4d}_populate_kernel()", " - kasan: fix GCC mem-intrinsic prefix with sw tags", " - ima: limit the number of ToMToU integrity violations", " - flexfiles/pNFS: fix NULL checks on result of", " ff_layout_choose_ds_for_read", " - SUNRPC: call xs_sock_process_cmsg for all cmsg", " - NFSv4: Don't clear capabilities that won't be reset", " - NFSv4: Clear the NFS_CAP_FS_LOCATIONS flag if it is not set", " - NFSv4: Clear the NFS_CAP_XATTR flag if not supported by the server", " - tracing: Fix tracing_marker may trigger page fault during", " preempt_disable", " - ftrace/samples: Fix function size computation", " - fs/nfs/io: make nfs_start_io_*() killable", " - NFS: Serialise O_DIRECT i/o and truncate()", " - NFSv4.2: Serialise O_DIRECT i/o and fallocate()", " - NFSv4.2: Serialise O_DIRECT i/o and clone range", " - NFSv4.2: Serialise O_DIRECT i/o and copy range", " - NFSv4/flexfiles: Fix layout merge mirror check.", " - s390/cpum_cf: Deny all sampling events by counter PMU", " - proc: fix type confusion in pde_set_flags()", " - EDAC/altera: Delete an inappropriate dma_free_coherent() call", " - compiler-clang.h: define __SANITIZE_*__ macros only when undefined", " - net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO runtime PM", " wakeups", " - mtd: rawnand: stm32_fmc2: fix ECC overwrite", " - fuse: check if copy_file_range() returns larger than requested size", " - fuse: prevent overflow in copy_file_range return value", " - mm/damon/core: set quota->charged_from to jiffies at first charge window", " - drm/mediatek: fix potential OF node use-after-free", " - drm/amdgpu/vcn: Allow limiting ctx to instance 0 for AV1 at any time", " - drm/amdgpu/vcn4: Fix IB parsing with multiple engine info packages", " - mtd: nand: raw: atmel: Fix comment in timings preparation", " - mtd: nand: raw: atmel: Respect tAR, tCLR in read setup timing", " - btrfs: use readahead_expand() on compressed extents", " - btrfs: fix corruption reading compressed range when block size is", " smaller than page size", " - mm/khugepaged: fix the address passed to notifier on testing young", " - Input: iqs7222 - avoid enabling unused interrupts", " - Input: i8042 - add TUXEDO InfinityBook Pro Gen10 AMD to i8042 quirk", " table", " - tty: hvc_console: Call hvc_kick in hvc_write unconditionally", " - serial: sc16is7xx: fix bug in flow control levels init", " - dt-bindings: serial: brcm,bcm7271-uart: Constrain clocks", " - USB: serial: option: add Telit Cinterion FN990A w/audio compositions", " - USB: serial: option: add Telit Cinterion LE910C4-WWX new compositions", " - net: bridge: Bounce invalid boolopts", " - tunnels: reset the GSO metadata before reusing the skb", " - docs: networking: can: change bcm_msg_head frames member to support", " flexible array", " - igb: fix link test skipping when interface is admin down", " - can: j1939: j1939_sk_bind(): call j1939_priv_put() immediately when", " j1939_local_ecu_get() failed", " - can: j1939: j1939_local_ecu_get(): undo increment when", " j1939_local_ecu_get() fails", " - net: hsr: Add VLAN CTAG filter support", " - hsr: use rtnl lock when iterating over ports", " - hsr: use hsr_for_each_port_rtnl in hsr_port_get_hsr", " - dmaengine: idxd: Remove improper idxd_free", " - dmaengine: idxd: Fix refcount underflow on module unload", " - dmaengine: idxd: Fix double free in idxd_setup_wqs()", " - regulator: sy7636a: fix lifecycle of power good gpio", " - hrtimer: Remove unused function", " - hrtimer: Rename __hrtimer_hres_active() to hrtimer_hres_active()", " - hrtimers: Unconditionally update target CPU base after offline timer", " migration", " - RISC-V: Remove unnecessary include from compat.h", " - xhci: fix memory leak regression when freeing xhci vdev devices depth", " first", " - USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels", " - usb: gadget: midi2: Fix missing UMP group attributes initialization", " - usb: gadget: midi2: Fix MIDI2 IN EP max packet size", " - dmaengine: dw: dmamux: Fix device reference leak in", " rzn1_dmamux_route_allocate", " - phy: tegra: xusb: fix device and OF node leak at probe", " - phy: ti-pipe3: fix device leak at unbind", " - net: mdiobus: release reset_gpio in mdiobus_unregister_device()", " - drm/amdgpu: fix a memory leak in fence cleanup when unloading", " - drm/i915/power: fix size for for_each_set_bit() in abox iteration", " - nvme-pci: skip nvme_write_sq_db on empty rqlist", " - ext4: introduce linear search for dentries", " - drm/i915/pmu: Fix zero delta busyness issue", " - drm/amd/display: Fix error pointers in amdgpu_dm_crtc_mem_type_changed", " - Revert \"drm/amd/display: Optimize cursor position updates\"", " - ALSA: hda/realtek: Fix built-in mic assignment on ASUS VivoBook X515UA", " - drm/amdgpu: Add back JPEG to video caps for carrizo and newer", " - trace/fgraph: Fix error handling", " - NFS: nfs_invalidate_folio() must observe the offset and size arguments", " - s390/pai: Deny all events not handled by this PMU", " - btrfs: fix squota compressed stats leak", " - netlink: specs: mptcp: add missing 'server-side' attr", " - netlink: specs: mptcp: clearly mention attributes", " - netlink: specs: mptcp: replace underscores with dashes in names", " - netlink: specs: mptcp: fix if-idx attribute type", " - ceph: fix race condition where r_parent becomes stale before sending", " message", " - mtd: spinand: winbond: Fix oob_layout for W25N01JW", " - Revert \"net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO", " runtime PM wakeups\"", " - drm/amd/display: use udelay rather than fsleep", " - netfilter: nft_set_rbtree: continue traversal if element is inactive", " - netfilter: nf_tables: place base_seq in struct net", " - netfilter: nf_tables: make nft_set_do_lookup available unconditionally", " - netfilter: nf_tables: restart set lookup on base_seq change", " - phy: qualcomm: phy-qcom-eusb2-repeater: fix override properties", " - phy: ti: omap-usb2: fix device leak at unbind", " - Upstream stable to v6.6.107, v6.12.48", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39927", " - ceph: fix race condition validating r_parent before applying state", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39923", " - dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39869", " - dmaengine: ti: edma: Fix memory allocation size for queue_priority_map", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39873", " - can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted", " SKB", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39911", " - i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39876", " - net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39881", " - kernfs: Fix UAF in polling when open file is released", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39909", " - mm/damon/lru_sort: avoid divide-by-zero in", " damon_lru_sort_apply_parameters()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39916", " - mm/damon/reclaim: avoid divide-by-zero in", " damon_reclaim_apply_parameters()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39877", " - mm/damon/sysfs: fix use-after-free in state_show()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39880", " - libceph: fix invalid accesses to ceph_connection_v1_info", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39883", " - mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison", " memory", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39907", " - mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39885", " - ocfs2: fix recursive semaphore deadlock in fiemap call", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39913", " - tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to", " allocate psock->cork.", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39886", " - bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39914", " - tracing: Silence warning when chunk allocation fails in trace_pid_write", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-23143", " - net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502)", " - bpf: Add cookie object to bpf maps", " - bpf: Move cgroup iterator helpers to bpf.h", " - btrfs: fix race between logging inode and checking if it was logged", " before", " - btrfs: fix race between setting last_dir_index_offset and inode logging", " - btrfs: avoid load/store tearing races when checking if an inode was", " logged", " - LoongArch: Save LBT before FPU in setup_sigcontext()", " - cdc_ncm: Flag Intel OEM version of Fibocom L850-GL as WWAN", " - drm/amd/display: Don't warn when missing DCE encoder caps", " - cpupower: Fix a bug where the -t option of the set subcommand was not", " working.", " - Bluetooth: hci_sync: Avoid adding default advertising on startup", " - arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3399-pinebook-pro", " - tee: optee: ffa: fix a typo of \"optee_ffa_api_is_compatible\"", " - arm64: dts: imx8mp: Fix missing microSD slot vqmmc on DH electronics", " i.MX8M Plus DHCOM", " - arm64: dts: imx8mp: Fix missing microSD slot vqmmc on Data Modul i.MX8M", " Plus eDM SBC", " - netfilter: conntrack: helper: Replace -EEXIST by -EBUSY", " - xirc2ps_cs: fix register access when enabling FullDuplex", " - mISDN: Fix memory leak in dsp_hwec_enable()", " - icmp: fix icmp_ndo_send address translation for reply direction", " - net: macb: Fix tx_ptr_lock locking", " - macsec: read MACSEC_SA_ATTR_PN with nla_get_uint", " - wifi: ath11k: rename ath11k_start_vdev_delay()", " - wifi: ath11k: avoid forward declaration of ath11k_mac_start_vdev_delay()", " - wifi: ath11k: fix group data packet drops during rekey", " - net: ethernet: mtk_eth_soc: fix tx vlan tag for llc packets", " - wifi: cw1200: cap SSID length in cw1200_do_join()", " - wifi: libertas: cap SSID len in lbs_associate()", " - net: thunder_bgx: add a missing of_node_put", " - net: thunder_bgx: decrement cleanup index before use", " - ipv4: Fix NULL vs error pointer check in inet_blackhole_dev_init()", " - net/smc: Remove validation of reserved bits in CLC Decline message", " - mctp: return -ENOPROTOOPT for unknown getsockopt options", " - net: atm: fix memory leak in atm_register_sysfs when device_register", " fail", " - selftest: net: Fix weird setsockopt() in bind_bhash.c.", " - phy: mscc: Stop taking ts_lock for tx_queue and use its own lock", " - ALSA: usb-audio: Add mute TLV for playback volumes on some devices", " - ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids()", " - arm64: ftrace: fix unreachable PLT for ftrace_caller in init_module with", " CONFIG_DYNAMIC_FTRACE", " - proc: fix missing pde_set_flags() for net proc files", " - soc: qcom: mdt_loader: Deal with zero e_shentsize", " - wifi: mt76: mt7996: Initialize hdr before passing to skb_put_data()", " - drm/amdgpu: drop hw access in non-DC audio fini", " - platform/x86/amd/pmc: Add TUXEDO IB Pro Gen10 AMD to spurious 8042", " quirks list", " - e1000e: fix heap overflow in e1000_set_eeprom", " - net: pcs: rzn1-miic: Correct MODCTRL register offset", " - cpufreq: intel_pstate: Fold intel_pstate_max_within_limits() into caller", " - cpufreq: intel_pstate: Do not update global.turbo_disabled after", " initialization", " - cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode", " - thermal/drivers/mediatek/lvts: Disable low offset IRQ for minimum", " threshold", " - PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads", " - dmaengine: mediatek: Fix a possible deadlock error in", " mtk_cqdma_tx_status()", " - ALSA: hda/hdmi: Add pin fix for another HP EliteDesk 800 G4 model", " - ALSA: hda/realtek: Fix headset mic for TongFang X6[AF]R5xxY", " - pcmcia: omap: Add missing check for platform_get_resource", " - hwmon: mlxreg-fan: Prevent fans from getting stuck at 0 RPM", " - spi: spi-fsl-lpspi: Fix transmissions when using CONT", " - spi: spi-fsl-lpspi: Set correct chip-select polarity bit", " - spi: spi-fsl-lpspi: Reset FIFO and disable module on transfer abort", " - spi: spi-fsl-lpspi: Clear status register after disabling the module", " - drm/bridge: ti-sn65dsi86: fix REFCLK setting", " - perf bpf-event: Fix use-after-free in synthesis", " - drm/amdgpu: Replace DRM_* with dev_* in amdgpu_psp.c", " - drm/amd/amdgpu: Fix missing error return on kzalloc failure", " - tools: gpio: rm .*.cmd on make clean", " - tools: gpio: remove the include directory on make clean", " - riscv: use lw when reading int cpu in asm_per_cpu", " - cpufreq: intel_pstate: Rearrange show_no_turbo() and store_no_turbo()", " - cpufreq: intel_pstate: Read global.no_turbo under READ_ONCE()", " - cpufreq: intel_pstate: Check turbo_is_disabled() in store_no_turbo()", " - dmaengine: mediatek: Fix a flag reuse error in mtk_cqdma_tx_status()", " - bpf: Move bpf map owner out of common struct", " - btrfs: zoned: skip ZONE FINISH of conventional zones", " - arm64: dts: imx8mp-tqma8mpql: fix LDO5 power off", " - HID: simplify snto32()", " - HID: stop exporting hid_snto32()", " - net: usb: qmi_wwan: fix Telit Cinterion FN990A name", " - net: usb: qmi_wwan: fix Telit Cinterion FE990A name", " - net: usb: qmi_wwan: add Telit Cinterion FN990A w/audio composition", " - LoongArch: vDSO: Remove --hash-style=sysv", " - LoongArch: vDSO: Remove -nostdlib complier flag", " - mmc: sdhci-of-arasan: Support for emmc hardware reset", " - mmc: sdhci-of-arasan: Ensure CD logic stabilization before power-up", " - bnxt_en: fix incorrect page count in RX aggr ring log", " - net: mctp: mctp_fraq_queue should take ownership of passed skb", " - idpf: set mac type when adding and removing MAC filters", " - net: skb: add pskb_network_may_pull_reason() helper", " - net: tunnel: add pskb_inet_may_pull_reason() helper", " - net: vxlan: add skb drop reasons to vxlan_rcv()", " - net: vxlan: make vxlan_snoop() return drop reasons", " - net: vxlan: make vxlan_set_mac() return drop reasons", " - net: vxlan: use kfree_skb_reason() in vxlan_xmit()", " - net: vxlan: use kfree_skb_reason() in vxlan_mdb_xmit()", " - net: vxlan: rename SKB_DROP_REASON_VXLAN_NO_REMOTE", " - vxlan: Refresh FDB 'updated' time upon 'NTF_USE'", " - vxlan: Avoid unnecessary updates to FDB 'used' time", " - vxlan: Add RCU read-side critical sections in the Tx path", " - vxlan: Rename FDB Tx lookup function", " - mm: fix possible deadlock in kmemleak", " - drm/amd/display: Clear the CUR_ENABLE register on DCN314 w/out DPP PG", " - net: dsa: add hook to determine whether EEE is supported", " - net: dsa: provide implementation of .support_eee()", " - md/raid1,raid10: don't handle IO error for REQ_RAHEAD and REQ_NOWAIT", " - md/raid1,raid10: strip REQ_NOWAIT from member bios", " - ext4: define ext4_journal_destroy wrapper", " - wifi: ath11k: update channel list in worker when wait flag is set", " - nouveau: fix disabling the nonstall irq due to storm code", " - kunit: kasan_test: disable fortify string checker on kasan_strings()", " test", " - platform/x86: asus-wmi: Remove extra keys from ignore_key_wlan quirk", " - perf bpf-utils: Constify bpil_array_desc", " - perf bpf-utils: Harden get_bpf_prog_info_linear", " - md/raid1: fix data lost for writemostly rdev", " - Upstream stable to v6.6.105, v6.6.106, v6.12.46, v6.12.47", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-22124", " - md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-22103", " - net: fix NULL pointer dereference in l3mdev_l3_rcv", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-23133", " - wifi: ath11k: update channel list in reg notifier instead reg worker", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-22113", " - ext4: avoid journaling sb update on error if journal is destroying", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-22125", " - md/raid1,raid10: don't ignore IO flags", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39899", " - mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39897", " - net: xilinx: axienet: Add error handling for RX metadata pointer", " retrieval", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39850", " - vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39851", " - vxlan: Fix NPD when refreshing an FDB entry with a nexthop object", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39852", " - net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39901", " - i40e: remove read access to debugfs files", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39854", " - ice: fix NULL access of tx->in_use in ice_ll_ts_intr", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-38556", " - HID: core: Harden s32ton() against conversion to 0 bits", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-38502", " - bpf: Fix oob access in cgroup local storage", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39843", " - mm: slub: avoid wake up kswapd in set_track_prepare", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39920", " - pcmcia: Add error handling for add_interval() in do_validate_mem()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39902", " - mm/slub: avoid accessing metadata when pointer is invalid in", " object_err()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39838", " - cifs: prevent NULL pointer dereference in UTF16 conversion", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39839", " - batman-adv: fix OOB read/write in network-coding decode", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39841", " - scsi: lpfc: Fix buffer free/clear order in deferred receive path", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39891", " - wifi: mwifiex: Initialize the chan_stats array to zero", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39842", " - ocfs2: prevent release journal inode after journal shutdown", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39895", " - sched: Fix sched_numa_find_nth_cpu() if mask offline", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39844", " - mm: move page table sync declarations to linux/pgtable.h", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39845", " - x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and", " arch_sync_kernel_mappings()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39846", " - pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39847", " - ppp: fix memory leak in pad_compress_skb", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39848", " - ax25: properly unshare skbs in ax25_kiss_rcv()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39849", " - wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39853", " - i40e: Fix potential invalid access when MAC list is empty", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39857", " - net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39860", " - Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39861", " - Bluetooth: vhci: Prevent use-after-free by removing debugfs files early", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39894", " - netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in()", " after confirm", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39863", " - wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info", " work", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39864", " - wifi: cfg80211: fix use-after-free in cmp_bss()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39865", " - tee: fix NULL pointer dereference in tee_shm_put", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39866", " - fs: writeback: fix use-after-free in __mark_inode_dirty()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664)", " - of: dynamic: Fix memleak when of_pci_add_properties() failed", " - pinctrl: STMFX: add missing HAS_IOMEM dependency", " - mips: dts: lantiq: danube: add missing burst length property", " - mips: lantiq: xway: sysctrl: rename the etop node", " - of: Add a helper to free property struct", " - of: dynamic: Fix use after free in of_changeset_add_prop_helper()", " - scsi: core: sysfs: Correct sysfs attributes access rights", " - smb: client: fix race with concurrent opens in unlink(2)", " - ASoC: codecs: tx-macro: correct tx_macro_component_drv name", " - erofs: fix atomic context detection when !CONFIG_DEBUG_LOCK_ALLOC", " - ACPI: EC: Add device to acpi_ec_no_wakeup[] qurik list", " - nfs: fold nfs_page_group_lock_subrequests into", " nfs_lock_and_join_requests", " - vhost/net: Protect ubufs with rcu read lock in vhost_net_ubuf_put()", " - net: ipv4: fix regression in local-broadcast routes", " - drm/msm: Defer fd_install in SUBMIT ioctl", " - powerpc/kvm: Fix ifdef to remove build warning", " - HID: input: rename hidinput_set_battery_charge_status()", " - HID: input: report battery status changes immediately", " - Bluetooth: hci_event: Treat UNKNOWN_CONN_ID on disconnect as success", " - Bluetooth: hci_event: Mark connection as closed during suspend", " disconnect", " - Bluetooth: hci_event: Detect if HCI_EV_NUM_COMP_PKTS is unbalanced", " - Bluetooth: hci_sync: fix set_local_name race condition", " - drm/nouveau: remove unused increment in gm200_flcn_pio_imem_wr", " - drm/nouveau: remove unused memory target test", " - ice: fix incorrect counter for buffer allocation failures", " - dt-bindings: display/msm: qcom,mdp5: drop lut clock", " - net: dlink: fix multicast stats being counted incorrectly", " - phy: mscc: Fix when PTP clock is register and unregister", " - net/mlx5: Reload auxiliary drivers on fw_activate", " - net/mlx5: Add device cap for supporting hot reset in sync reset flow", " - net/mlx5: Add support for sync reset using hot reset", " - net/mlx5: Nack sync reset when SFs are present", " - net/mlx5e: Set local Xoff after FW update", " - net: stmmac: xgmac: Do not enable RX FIFO Overflow interrupts", " - net: stmmac: Rename phylink_get_caps() callback to update_caps()", " - net: stmmac: xgmac: Correct supported speed modes", " - net: stmmac: Set CIC bit only for TX queues with COE", " - net: rose: split remove and free operations in rose_remove_neigh()", " - x86/microcode/AMD: Handle the case of no BIOS microcode", " - HID: quirks: add support for Legion Go dual dinput modes", " - HID: logitech: Add ids for G PRO 2 LIGHTSPEED", " - HID: wacom: Add a new Art Pen 2", " - dma/pool: Ensure DMA_DIRECT_REMAP allocations are decrypted", " - net: usb: qmi_wwan: add Telit Cinterion LE910C4-WWX new compositions", " - smb3 client: fix return code mapping of remap_file_range", " - drm/nouveau/disp: Always accept linear modifier", " - net: rose: fix a typo in rose_clear_routes()", " - perf symbol-minimal: Fix ehdr reading in filename__read_build_id", " - vhost: Fix ioctl # for VHOST_[GS]ET_FORK_FROM_OWNER", " - drm/msm/kms: move snapshot init earlier in KMS init", " - drm/mediatek: Add error handling for old state CRTC in atomic_disable", " - drm/xe/xe_sync: avoid race during ufence signaling", " - drm/xe: Don't trigger rebind on initial dma-buf validation", " - bnxt_en: Adjust TX rings if reservation is less than requested", " - hv_netvsc: Link queues to NAPIs", " - net: hv_netvsc: fix loss of early receive events from host during", " channel open.", " - net: macb: Disable clocks once", " - drm/nouveau: fix error path in nvkm_gsp_fwsec_v2", " - drm/mediatek: Fix device/node reference count leaks in", " mtk_drm_get_all_drm_priv", " - drm/amd/amdgpu: disable hwmon power1_cap* for gfx 11.0.3 on vf mode", " - PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value", " - PCI: Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to", " PCIE_RESET_CONFIG_WAIT_MS", " - PCI: dwc: Rename 'dw_pcie::link_gen' to 'dw_pcie::max_link_speed'", " - PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link up", " - thermal/drivers/mediatek/lvts_thermal: Change lvts commands array to", " static const", " - thermal/drivers/mediatek/lvts_thermal: Add lvts commands and their sizes", " to driver data", " - thermal/drivers/mediatek/lvts_thermal: Add mt7988 lvts commands", " - Upstream stable to v6.6.104, v6.12.45", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39811", " - drm/xe/vm: Clear the scratch_pt pointer on error", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39815", " - RISC-V: KVM: fix stack overrun when loading vlenb", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39810", " - bnxt_en: Fix memory corruption when FW resources change during ifdown", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39836", " - efi: stmm: Fix incorrect buffer allocation method", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39805", " - net: macb: fix unregister_netdev call order in macb_remove()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39829", " - trace/fgraph: Fix the warning caused by missing unregister notifier", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39835", " - xfs: do not propagate ENODATA disk errors into xattr code", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39819", " - fs/smb: Fix inconsistent refcnt update", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39808", " - HID: hid-ntrig: fix unable to handle page fault in", " ntrig_report_version()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39806", " - HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39824", " - HID: asus: fix UAF via HID_CLAIMED_INPUT validation", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39823", " - KVM: x86: use array_index_nospec with indices that come from guest", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39817", " - efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39812", " - sctp: initialize more fields in sctp_v6_from_sk()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39827", " - net: rose: include node references in rose_neigh refcount", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39826", " - net: rose: convert 'use' field to refcount_t", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39832", " - net/mlx5: Fix lockdep assertion on sync reset unload event", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39828", " - atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39697", " - NFS: Fix a race when updating an existing write", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39825", " - smb: client: fix race with concurrent opens in rename(2)", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39813", " - ftrace: Fix potential warning in trace_printk_seq during ftrace_dump", "", " * CVE-2025-37899", " - ksmbd: fix use-after-free in session logoff", "", " * CVE-2025-22037", " - ksmbd: mark SMB2_SESSION_EXPIRED to session when destroying previous", " session", " - ksmbd: fix race condition between destroy_previous_session() and smb2", " operations()", " - ksmbd: fix null pointer dereference in alloc_preauth_hash()", "" ], "package": "linux", "version": "6.8.0-103.103", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141411, 1786013, 2141314, 2127764, 2137613, 2138120, 2136958, 2130240, 2067642, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664 ], "author": "Edoardo Canepa ", "date": "Tue, 10 Feb 2026 12:14:34 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-tools-common", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-101.101", "version": "6.8.0-101.101" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-106.106", "version": "6.8.0-106.106" }, "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68198", "url": "https://ubuntu.com/security/CVE-2025-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crash: fix crashkernel resource shrink When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues: 1. Invalid crashkernel resource objects 2. Kernel crash if crashkernel shrinking is done twice For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as: cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel Instead, it should show 50MB: af000000-b21fffff : Crash kernel Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86): BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated. Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-38627", "url": "https://ubuntu.com/security/CVE-2025-38627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic The decompress_io_ctx may be released asynchronously after I/O completion. If this file is deleted immediately after read, and the kworker of processing post_read_wq has not been executed yet due to high workloads, It is possible that the inode(f2fs_inode_info) is evicted and freed before it is used f2fs_free_dic. The UAF case as below: Thread A Thread B - f2fs_decompress_end_io - f2fs_put_dic - queue_work add free_dic work to post_read_wq - do_unlink - iput - evict - call_rcu This file is deleted after read. Thread C kworker to process post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inode is freed by rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem read (dic->inode)->i_compress_algorithm This patch store compress_algorithm and sbi in dic to avoid inode UAF. In addition, the previous solution is deprecated in [1] may cause system hang. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68204", "url": "https://ubuntu.com/security/CVE-2025-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: arm: scmi: Fix genpd leak on provider registration failure If of_genpd_add_provider_onecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpd_debug_add(). Add proper error handling to unwind the initialized domains before returning from probe to ensure all resources are correctly released on failure. Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39981", "url": "https://ubuntu.com/security/CVE-2025-39981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible UAFs This attemps to fix possible UAFs caused by struct mgmt_pending being freed while still being processed like in the following trace, in order to fix mgmt_pending_valid is introduce and use to check if the mgmt_pending hasn't been removed from the pending list, on the complete callbacks it is used to check and in addtion remove the cmd from the list while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd is left on the list it can still be accessed and freed. BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55 CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 Allocated by task 12210: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x258/0x330 net/socket.c:1133 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 12221: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-22121", "url": "https://ubuntu.com/security/CVE-2025-22121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-23129", "url": "https://ubuntu.com/security/CVE-2025-23129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath11k_pci_alloc_msi(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This results in the below warning: WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c Call trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc The warning is due to not clearing the affinity hint before freeing the IRQs. So to fix this issue, clear the IRQ affinity hint before calling ath11k_pcic_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-40287", "url": "https://ubuntu.com/security/CVE-2025-40287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix improper check of dentry.stream.valid_size We found an infinite loop bug in the exFAT file system that can lead to a Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is malformed, the following system calls — SYS_openat, SYS_ftruncate, and SYS_pwrite64 — can cause the kernel to hang. Root cause analysis shows that the size validation code in exfat_find() does not check whether dentry.stream.valid_size is negative. As a result, the system calls mentioned above can succeed and eventually trigger the DoS issue. This patch adds a check for negative dentry.stream.valid_size to prevent this vulnerability.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40289", "url": "https://ubuntu.com/security/CVE-2025-40289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM Otherwise accessing them can cause a crash.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68201", "url": "https://ubuntu.com/security/CVE-2025-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: remove two invalid BUG_ON()s Those can be triggered trivially by userspace.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68180", "url": "https://ubuntu.com/security/CVE-2025-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref in debugfs odm_combine_segments When a connector is connected but inactive (e.g., disabled by desktop environments), pipe_ctx->stream_res.tg will be destroyed. Then, reading odm_combine_segments causes kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Fix this by checking pipe_ctx-> ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68322", "url": "https://ubuntu.com/security/CVE-2025-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Avoid crash due to unaligned access in unwinder Guenter Roeck reported this kernel crash on his emulated B160L machine: Starting network: udhcpc: started, v1.36.1 Backtrace: [<104320d4>] unwind_once+0x1c/0x5c [<10434a00>] walk_stackframe.isra.0+0x74/0xb8 [<10434a6c>] arch_stack_walk+0x28/0x38 [<104e5efc>] stack_trace_save+0x48/0x5c [<105d1bdc>] set_track_prepare+0x44/0x6c [<105d9c80>] ___slab_alloc+0xfc4/0x1024 [<105d9d38>] __slab_alloc.isra.0+0x58/0x90 [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0 [<105b8e54>] __anon_vma_prepare+0x60/0x280 [<105a823c>] __vmf_anon_prepare+0x68/0x94 [<105a8b34>] do_wp_page+0x8cc/0xf10 [<105aad88>] handle_mm_fault+0x6c0/0xf08 [<10425568>] do_page_fault+0x110/0x440 [<10427938>] handle_interruption+0x184/0x748 [<11178398>] schedule+0x4c/0x190 BUG: spinlock recursion on CPU#0, ifconfig/2420 lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0 While creating the stack trace, the unwinder uses the stack pointer to guess the previous frame to read the previous stack pointer from memory. The crash happens, because the unwinder tries to read from unaligned memory and as such triggers the unalignment trap handler which then leads to the spinlock recursion and finally to a deadlock. Fix it by checking the alignment before accessing the memory.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40305", "url": "https://ubuntu.com/security/CVE-2025-40305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq) if list_empty(&m->req_list). However, if the pipe is full, we need to read more data and this used to work prior to commit aaec5a95d59615 (\"pipe_read: don't wake up the writer if the pipe is still full\"). p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before the commit above) triggered the unnecessary wakeup. This wakeup calls p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux() will notice EPOLLIN and schedule_work(&m->rq). This no longer happens after the optimization above, change p9_fd_request() to use p9_poll_mux() instead of only checking for EPOLLOUT.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40307", "url": "https://ubuntu.com/security/CVE-2025-40307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: validate cluster allocation bits of the allocation bitmap syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68315", "url": "https://ubuntu.com/security/CVE-2025-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to detect potential corrupted nid in free_nid_list As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40339", "url": "https://ubuntu.com/security/CVE-2025-40339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix nullptr err of vm_handle_moved If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68311", "url": "https://ubuntu.com/security/CVE-2025-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: ip22zilog: Use platform device for probing After commit 84a9582fd203 (\"serial: core: Start managing serial controllers to enable runtime PM\") serial drivers need to provide a device in struct uart_port.dev otherwise an oops happens. To fix this issue for ip22zilog driver switch driver to a platform driver and setup the serial device in sgi-ip22 code.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68313", "url": "https://ubuntu.com/security/CVE-2025-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Add RDSEED fix for Zen5 There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 \"at a rate inconsistent with randomness while incorrectly signaling success (CF=1)\". Search the web for AMD-SB-7055 for more detail. Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40360", "url": "https://ubuntu.com/security/CVE-2025-40360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Do not dereference NULL pointer in plane reset The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68734", "url": "https://ubuntu.com/security/CVE-2025-68734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe() In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style. Compile tested only. Issue found using a prototype static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-40272", "url": "https://ubuntu.com/security/CVE-2025-40272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix use-after-free race in fault handler When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40077", "url": "https://ubuntu.com/security/CVE-2025-40077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid overflow while left shift operation Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-68245", "url": "https://ubuntu.com/security/CVE-2025-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit efa95b01da18 (\"netpoll: fix use after free\") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 (\"netpoll: fix use after free\") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40293", "url": "https://ubuntu.com/security/CVE-2025-40293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Don't overflow during division for dirty tracking If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow to 0 and this triggers divide by 0. In this case the index should just be 0, so reorganize things to divide by shift and avoid hitting any overflows.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40303", "url": "https://ubuntu.com/security/CVE-2025-40303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: ensure no dirty metadata is written back for an fs with errors [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68184", "url": "https://ubuntu.com/security/CVE-2025-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Disable AFBC support on Mediatek DRM driver Commit c410fa9b07c3 (\"drm/mediatek: Add AFBC support to Mediatek DRM driver\") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier. However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0. Kernel trace reports vblank timeouts constantly, and the render is garbled: ``` [CRTC:62:crtc-0] vblank wait timed out WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c [...] Hardware name: MediaTek Genio-700 EVK (DT) Workqueue: events_unbound commit_work pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c sp : ffff80008337bca0 x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000 x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70 x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ``` Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40268", "url": "https://ubuntu.com/security/CVE-2025-40268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: client: fix memory leak in smb3_fs_context_parse_param The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation. To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing. syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444 BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40269", "url": "https://ubuntu.com/security/CVE-2025-40269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential overflow of PCM transfer buffer The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0].", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40271", "url": "https://ubuntu.com/security/CVE-2025-40271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix uaf in proc_readdir_de() Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \\ NULL pde(tun2)", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68241", "url": "https://ubuntu.com/security/CVE-2025-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random. The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked. CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak] This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = N Ido Schimmel provided the simple test validation method [1]. The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed. [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \\ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \\ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \\ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-68246", "url": "https://ubuntu.com/security/CVE-2025-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: close accepted socket when per-IP limit rejects connection When the per-IP connection limit is exceeded in ksmbd_kthread_fn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS. Release client_sk before continuing. This bug was found with ZeroPath.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40273", "url": "https://ubuntu.com/security/CVE-2025-40273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: free copynotify stateid in nfs4_free_ol_stateid() Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period. However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd] This patch, instead, frees the associated copynotify stateid here. If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later. [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68208", "url": "https://ubuntu.com/security/CVE-2025-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: account for current allocated stack depth in widen_imprecise_scalars() The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st); Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loop Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68200", "url": "https://ubuntu.com/security/CVE-2025-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add bpf_prog_run_data_pointers() syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 (\"net/sched: Extend qdisc control block with tc control block\"), which added a wrong interaction with db58ba459202 (\"bpf: wire in data and data_end for cls_act_bpf\"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40275", "url": "https://ubuntu.com/security/CVE-2025-40275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd In snd_usb_create_streams(), for UAC version 3 devices, the Interface Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this call fails, a fallback routine attempts to obtain the IAD from the next interface and sets a BADD profile. However, snd_usb_mixer_controls_badd() assumes that the IAD retrieved from usb_ifnum_to_if() is always valid, without performing a NULL check. This can lead to a NULL pointer dereference when usb_ifnum_to_if() fails to find the interface descriptor. This patch adds a NULL pointer check after calling usb_ifnum_to_if() in snd_usb_mixer_controls_badd() to prevent the dereference. This issue was discovered by syzkaller, which triggered the bug by sending a crafted USB device descriptor.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40277", "url": "https://ubuntu.com/security/CVE-2025-40277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40278", "url": "https://ubuntu.com/security/CVE-2025-40278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak Fix a KMSAN kernel-infoleak detected by the syzbot . [net?] KMSAN: kernel-infoleak in __skb_datagram_iter In tcf_ife_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. This change silences the KMSAN report and prevents potential information leaks from the kernel memory. This fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures no infoleak.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40279", "url": "https://ubuntu.com/security/CVE-2025-40279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_connmark: initialize struct tc_ife to fix kernel leak In tcf_connmark_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40280", "url": "https://ubuntu.com/security/CVE-2025-40280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_mon_reinit_self(). syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0] The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL. tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work(). Let's hold RTNL in tipc_net_finalize_work(). [0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989 CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40281", "url": "https://ubuntu.com/security/CVE-2025-40281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto syzbot reported a possible shift-out-of-bounds [1] Blamed commit added rto_alpha_max and rto_beta_max set to 1000. It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta. In order to prevent user regression, perform the test at run time. Also add READ_ONCE() annotations as sysctl values can change under us. [1] UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40282", "url": "https://ubuntu.com/security/CVE-2025-40282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: 6lowpan: reset link-local header on ipv6 recv path Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW Add missing skb_reset_mac_header() for uncompressed ipv6 RX path. For the compressed one, it is done in lowpan_header_decompress(). Log: (BlueZ 6lowpan-tester Client Recv Raw - Success) ------ kernel BUG at net/core/skbuff.c:212! Call Trace: ... packet_rcv (net/packet/af_packet.c:2152) ... __local_bh_enable_ip (kernel/softirq.c:407) netif_rx (net/core/dev.c:5648) chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359) ------", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40283", "url": "https://ubuntu.com/security/CVE-2025-40283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF There is a KASAN: slab-use-after-free read in btusb_disconnect(). Calling \"usb_driver_release_interface(&btusb_driver, data->intf)\" will free the btusb data associated with the interface. The same data is then used later in the function, hence the UAF. Fix by moving the accesses to btusb data to before the data is free'd.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40284", "url": "https://ubuntu.com/security/CVE-2025-40284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in \"Mesh - Send cancel - 1\" test). Log: ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40285", "url": "https://ubuntu.com/security/CVE-2025-40285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix possible refcount leak in smb2_sess_setup() Reference count of ksmbd_session will leak when session need reconnect. Fix this by adding the missing ksmbd_user_session_put().", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40286", "url": "https://ubuntu.com/security/CVE-2025-40286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix possible memory leak in smb2_read() Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree().", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40288", "url": "https://ubuntu.com/security/CVE-2025-40288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices Previously, APU platforms (and other scenarios with uninitialized VRAM managers) triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL, but that `man->bdev` (the backing device pointer within the manager) remains uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to a kernel OOPS. 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference. 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL. 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report). This approach is more robust than APU-specific checks because it: - Works for all scenarios where the VRAM manager is uninitialized (not just APUs), - Aligns with TTM's design by using its native helper function, - Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check). v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68244", "url": "https://ubuntu.com/security/CVE-2025-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x16 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40292", "url": "https://ubuntu.com/security/CVE-2025-40292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix received length check in big packets Since commit 4959aebba8c0 (\"virtio-net: use mtu size as buffer length for big packets\"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40328", "url": "https://ubuntu.com/security/CVE-2025-40328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_close_cached_fid() find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free. Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40294", "url": "https://ubuntu.com/security/CVE-2025-40294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern() In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied. Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40329", "url": "https://ubuntu.com/security/CVE-2025-40329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()). CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0. Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock This will deadlock if f1 and f2 share the same spinlock. To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work(). [phasta: commit message nits]", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68320", "url": "https://ubuntu.com/security/CVE-2025-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix sleeping in atomic context The following warning was seen when we try to connect using ssh to the device. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear preempt_count: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE Tainted: [W]=WARN Hardware name: Generic DT based system Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8 It seems that we are using a mutex in a atomic context which is wrong. Change the mutex with a spinlock.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68192", "url": "https://ubuntu.com/security/CVE-2025-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks. Initialize the MAC header to prevent such crashes. This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface. Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40331", "url": "https://ubuntu.com/security/CVE-2025-40331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: Prevent TOCTOU out-of-bounds write For the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use).", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40301", "url": "https://ubuntu.com/security/CVE-2025-40301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: validate skb length for unknown CC opcode In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory. The fix is to check skb->len before using skb->data.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40358", "url": "https://ubuntu.com/security/CVE-2025-40358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: stacktrace: Disable KASAN checks for non-current tasks Unwinding the stack of a task other than current, KASAN would report \"BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460\" There is a same issue on x86 and has been resolved by the commit 84936118bdf3 (\"x86/unwind: Disable KASAN checks for non-current tasks\") The solution could be applied to RISC-V too. This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23 [pjw@kernel.org: clean up checkpatch issues]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40304", "url": "https://ubuntu.com/security/CVE-2025-40304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches. Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68183", "url": "https://ubuntu.com/security/CVE-2025-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with \"ima_appraise=fix evm=fix ima_policy=appraise_tcb\" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = \"/usr/sbin/test_binary\"; const char* hex_string = \"030204d33204490066306402304\"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror(\"Error opening file\"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, \"%2hhx\", &ima_attr_value[j]); } if (fsetxattr(fd, \"security.ima\", ima_attr_value, length/2, 0) == -1) { perror(\"Error setting extended attribute\"); close(fd); return 1; } const char* selinux_value= \"system_u:object_r:bin_t:s0\"; if (fsetxattr(fd, \"security.selinux\", selinux_value, strlen(selinux_value), 0) == -1) { perror(\"Error setting extended attribute\"); close(fd); return 1; } close(fd); return 0; }", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68173", "url": "https://ubuntu.com/security/CVE-2025-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix softlockup in ftrace_module_enable A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc (\"ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels\") and commit 42ea22e754ba (\"ftrace: Add cond_resched() to ftrace_graph_set_hash()\"). Fix it the same way by adding cond_resched() in ftrace_module_enable.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40306", "url": "https://ubuntu.com/security/CVE-2025-40306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau forwarded me a message from Disclosure with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr \"security.capability\" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for \"security.capability\" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40308", "url": "https://ubuntu.com/security/CVE-2025-40308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bcsp: receive data only if registered Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40309", "url": "https://ubuntu.com/security/CVE-2025-40309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on sco_conn_free BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline] BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline] BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352 CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci13 hci_cmd_sync_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40310", "url": "https://ubuntu.com/security/CVE-2025-40310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw There is race in amdgpu_amdkfd_device_fini_sw and interrupt. if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated. kernel panic log: BUG: kernel NULL pointer dereference, address: 0000000000000098 amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP PGD d78c68067 P4D d78c68067 kfd kfd: amdgpu: Allocated 3969056 bytes on gart PUD 1465b8067 PMD @ Oops: @002 [#1] SMP NOPTI kfd kfd: amdgpu: Total number of KFD nodes to be created: 4 CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40 Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc 89 c6 e8 07 38 5d RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018 0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098 ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020 0000000000000000 R11: 0000000000000000 R12: 0900000000000002 ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00 CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033 CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400 PKRU: 55555554 Call Trace: kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu] ? amdgpu_fence_process+0xa4/0x150 [amdgpu] kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace amdgpu_irq_dispatch+0x165/0x210 [amdgpu] amdgpu_ih_process+0x80/0x100 [amdgpu] amdgpu: Virtual CRAT table created for GPU amdgpu_irq_handler+0x1f/@x60 [amdgpu] __handle_irq_event_percpu+0x3d/0x170 amdgpu: Topology: Add dGPU node [0x74a2:0x1002] handle_irq_event+0x5a/@xcO handle_edge_irq+0x93/0x240 kfd kfd: amdgpu: KFD node 1 partition @ size 49148M asm_call_irq_on_stack+0xf/@x20 common_interrupt+0xb3/0x130 asm_common_interrupt+0x1le/0x40 5.10.134-010.a1i5000.a18.x86_64 #1", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40311", "url": "https://ubuntu.com/security/CVE-2025-40311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: support mapping cb with vmalloc-backed coherent memory When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction. Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68185", "url": "https://ubuntu.com/security/CVE-2025-68185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68176", "url": "https://ubuntu.com/security/CVE-2025-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: cadence: Check for the existence of cdns_pcie::ops before using it cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. [mani: reworded subject and description]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68168", "url": "https://ubuntu.com/security/CVE-2025-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix uninitialized waitqueue in transaction manager The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems. When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0. This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEnd Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40312", "url": "https://ubuntu.com/security/CVE-2025-40312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Verify inode mode when loading from disk The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 (\"isofs: Verify inode mode when loading from disk\") does.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40333", "url": "https://ubuntu.com/security/CVE-2025-40333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix infinite loop in __insert_extent_tree() When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68321", "url": "https://ubuntu.com/security/CVE-2025-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: page_pool: always add GFP_NOWARN for ATOMIC allocations Driver authors often forget to add GFP_NOWARN for page allocation from the datapath. This is annoying to users as OOMs are a fact of life, and we pretty much expect network Rx to hit page allocation failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations by default.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68191", "url": "https://ubuntu.com/security/CVE-2025-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: use netdev_warn() instead of netdev_WARN() netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug. udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug. Replace netdev_WARN() with netdev_warn() accordingly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40313", "url": "https://ubuntu.com/security/CVE-2025-40313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: pretend $Extend records as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40314", "url": "https://ubuntu.com/security/CVE-2025-40314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free. Fix: By separating the usb_del_gadget_udc() operation into distinct \"del\" and \"put\" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget(). A patch similar to bb9c74a5bd14(\"usb: dwc3: gadget: Free gadget structure only after freeing endpoints\").", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40337", "url": "https://ubuntu.com/security/CVE-2025-40337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Correctly handle Rx checksum offload errors The stmmac_rx function would previously set skb->ip_summed to CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype. However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause corrupt packets to be passed up the network stack as valid. This patch corrects the logic by checking the `csum_none` status flag, which is set when the hardware reports a checksum error. If this flag is set, skb->ip_summed is now correctly set to CHECKSUM_NONE, ensuring the kernel's network stack will perform its own validation and properly handle the corrupt packet.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68194", "url": "https://ubuntu.com/security/CVE-2025-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imon: make send_packet() more robust syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1]. First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls). Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away. but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed. Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb). Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf (\"[media] imon: don't wedge hardware after early callbacks\"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a (\"[media] imon: don't parse scancodes until intf configured\") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task). Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40363", "url": "https://ubuntu.com/security/CVE-2025-40363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix field-spanning memcpy warning in AH output Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field \"&top_iph->saddr\" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439 The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68178", "url": "https://ubuntu.com/security/CVE-2025-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix possible deadlock while configuring policy Following deadlock can be triggered easily by lockdep: WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180 but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30 -> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock); Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context. The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40341", "url": "https://ubuntu.com/security/CVE-2025-40341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Don't leak robust_list pointer on exec race sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged. A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec(). For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process. This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk. Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40342", "url": "https://ubuntu.com/security/CVE-2025-40342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: use lock accessing port_state and rport state nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40343", "url": "https://ubuntu.com/security/CVE-2025-40343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid scheduling association deletion twice When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68177", "url": "https://ubuntu.com/security/CVE-2025-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq/longhaul: handle NULL policy in longhaul_exit longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic. This patch adds a check using unlikely() and returns early if the policy is NULL. Bugzilla: #219962", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40315", "url": "https://ubuntu.com/security/CVE-2025-40315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix epfile null pointer access after ep enable. A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable(). The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock. Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68310", "url": "https://ubuntu.com/security/CVE-2025-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do. During error recovery testing a pair of tasks was reported to be hung: mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core] No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too: - task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock() - task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock. A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/ reporter fw_fatal while PCI error recovery is executed on the same physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with \"kernel answers: Permission denied\" - and we get a kernel log message of: mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5 because the config read of VSC_SEMAPHORE is rejected by the underlying hardware. Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68179", "url": "https://ubuntu.com/security/CVE-2025-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible crashes. The problem is that kernel page tables are modified without flushing corresponding TLB entries. Even if it looks like the empty flush_tlb_all() implementation on s390 is the problem, it is actually a different problem: on s390 it is not allowed to replace an active/valid page table entry with another valid page table entry without the detour over an invalid entry. A direct replacement may lead to random crashes and/or data corruption. In order to invalidate an entry special instructions have to be used (e.g. ipte or idte). Alternatively there are also special instructions available which allow to replace a valid entry with a different valid entry (e.g. crdte or cspg). Given that the HVO code currently does not provide the hooks to allow for an implementation which is compliant with the s390 architecture requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is basically a revert of the original patch which enabled it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40317", "url": "https://ubuntu.com/security/CVE-2025-40317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: slimbus: fix bus_context pointer in regmap init calls Commit 4e65bda8273c (\"ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()\") revealed the problem in the slimbus regmap. That commit breaks audio playback, for instance, on sdm845 Thundercomm Dragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19c The __devm_regmap_init_slimbus() started to be used instead of __regmap_init_slimbus() after the commit mentioned above and turns out the incorrect bus_context pointer (3rd argument) was used in __devm_regmap_init_slimbus(). It should be just \"slimbus\" (which is equal to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or the first user of devm_regmap_init_slimbus() but we should fix it till the point where __devm_regmap_init_slimbus() was introduced therefore two \"Fixes\" tags. While at this, also correct the same argument in __regmap_init_slimbus().", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40318", "url": "https://ubuntu.com/security/CVE-2025-40318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and \"UAF\". Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68312", "url": "https://ubuntu.com/security/CVE-2025-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Prevents free active kevent The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the \"free active object (kevent)\" error reported here. 2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed. The solution to this problem is to cancel the kevent before executing free_netdev().", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68172", "url": "https://ubuntu.com/security/CVE-2025-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aspeed - fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the manual clock cleanup in both aspeed_acry_probe()'s error path and aspeed_acry_remove().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40319", "url": "https://ubuntu.com/security/CVE-2025-40319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Sync pending IRQ work before freeing ring buffer Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work complete before freeing the buffer.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68171", "url": "https://ubuntu.com/security/CVE-2025-68171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Ensure XFD state on signal delivery Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40320", "url": "https://ubuntu.com/security/CVE-2025-40320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential cfid UAF in smb2_query_info_compound When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free. Reinitialize cfid to NULL under the replay label. Example trace (trimmed): refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40321", "url": "https://ubuntu.com/security/CVE-2025-40321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the \"actframe\" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for \"send_af_done\" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. [Cc stable]", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40322", "url": "https://ubuntu.com/security/CVE-2025-40322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_putcs* bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40211", "url": "https://ubuntu.com/security/CVE-2025-40211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: video: Fix use-after-free in acpi_video_switch_brightness() The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed. [ rjw: Changelog edit ]", "cve_priority": "medium", "cve_public_date": "2025-11-21 11:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40324", "url": "https://ubuntu.com/security/CVE-2025-40324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix crash in nfsd4_read_release() When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-37860", "url": "https://ubuntu.com/security/CVE-2025-37860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: fix NULL dereferences in ef100_process_design_param() Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point. Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err.", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21833", "url": "https://ubuntu.com/security/CVE-2025-21833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE There is a WARN_ON_ONCE to catch an unlikely situation when domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless happens we must avoid using a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-22105", "url": "https://ubuntu.com/security/CVE-2025-22105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: check xdp prog when set bond mode Following operations can trigger a warning[1]: ip netns add ns1 ip netns exec ns1 ip link add bond0 type bond mode balance-rr ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp ip netns exec ns1 ip link set bond0 type bond mode broadcast ip netns del ns1 When delete the namespace, dev_xdp_uninstall() is called to remove xdp program on bond dev, and bond_xdp_set() will check the bond mode. If bond mode is changed after attaching xdp program, the warning may occur. Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode with xdp program attached is not good. Add check for xdp program when set bond mode. [1] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930 Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ... RSP: 0018:ffffc90000063d80 EFLAGS: 00000282 RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48 RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8 R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000 FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0 Call Trace: ? __warn+0x83/0x130 ? unregister_netdevice_many_notify+0x8d9/0x930 ? report_bug+0x18e/0x1a0 ? handle_bug+0x54/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? unregister_netdevice_many_notify+0x8d9/0x930 ? bond_net_exit_batch_rtnl+0x5c/0x90 cleanup_net+0x237/0x3d0 process_one_work+0x163/0x390 worker_thread+0x293/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0xec/0x1e0 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-23130", "url": "https://ubuntu.com/security/CVE-2025-23130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid panic once fallocation fails for pinfile syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation. In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg()", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-40353", "url": "https://ubuntu.com/security/CVE-2025-40353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: mte: Do not warn if the page is already tagged in copy_highpage() The arm64 copy_highpage() assumes that the destination page is newly allocated and not MTE-tagged (PG_mte_tagged unset) and warns accordingly. However, following commit 060913999d7a (\"mm: migrate: support poisoned recover from migrate folio\"), folio_mc_copy() is called before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the copy will be done again to the same destination page. Since copy_highpage() already set the PG_mte_tagged flag, this second copy will warn. Replace the WARN_ON_ONCE(page already tagged) in the arm64 copy_highpage() with a comment.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-39678", "url": "https://ubuntu.com/security/CVE-2025-39678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL If metric table address is not allocated, accessing metrics_bin will result in a NULL pointer dereference, so add a check.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-40235", "url": "https://ubuntu.com/security/CVE-2025-40235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots() If fs_info->super_copy or fs_info->super_for_commit allocated failed in btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info(). Otherwise btrfs_check_leaked_roots() would access NULL pointer because fs_info->allocated_roots had not been initialised. syzkaller reported the following information: ------------[ cut here ]------------ BUG: unable to handle page fault for address: fffffffffffffbb0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...) RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline] RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline] RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline] RIP: 0010:refcount_read include/linux/refcount.h:170 [inline] RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230 [...] Call Trace: btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280 btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029 btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097 vfs_get_tree+0x98/0x320 fs/super.c:1759 do_new_mount+0x357/0x660 fs/namespace.c:3899 path_mount+0x716/0x19c0 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount fs/namespace.c:4427 [inline] __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f032eaffa8d [...]", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40238", "url": "https://ubuntu.com/security/CVE-2025-40238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix IPsec cleanup over MPV device When we do mlx5e_detach_netdev() we eventually disable blocking events notifier, among those events are IPsec MPV events from IB to core. So before disabling those blocking events, make sure to also unregister the devcom device and mark all this device operations as complete, in order to prevent the other device from using invalid netdev during future devcom events which could cause the trace below. BUG: kernel NULL pointer dereference, address: 0000000000000010 PGD 146427067 P4D 146427067 PUD 146488067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40 RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206 RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00 RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000 R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600 R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80 FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core] mlx5_devcom_send_event+0x8c/0x170 [mlx5_core] blocking_event+0x17b/0x230 [mlx5_core] notifier_call_chain+0x35/0xa0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core] mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib] mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib] ? idr_alloc_cyclic+0x50/0xb0 ? __kmalloc_cache_noprof+0x167/0x340 ? __kmalloc_noprof+0x1a7/0x430 __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe9/0x310 [mlx5_ib] ? kernfs_add_one+0x107/0x150 ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] auxiliary_bus_probe+0x3e/0x90 really_probe+0xc5/0x3a0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x62d/0x830 __auxiliary_device_add+0x3b/0xa0 ? auxiliary_device_init+0x41/0x90 add_adev+0xd1/0x150 [mlx5_core] mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core] esw_mode_change+0x6c/0xc0 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x180/0x2b0 ? devlink_get_from_attrs_lock+0x170/0x170 ? devlink_nl_eswitch_get_doit+0x290/0x290 ? devlink_nl_pre_doit_port_optional+0x50/0x50 ? genl_family_rcv_msg_dumpit+0xf0/0xf0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1fc/0x2d0 netlink_sendmsg+0x1e4/0x410 __sock_sendmsg+0x38/0x60 ? sockfd_lookup_light+0x12/0x60 __sys_sendto+0x105/0x160 ? __sys_recvmsg+0x4e/0x90 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f27bc91b13a Code: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40242", "url": "https://ubuntu.com/security/CVE-2025-40242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix unlikely race in gdlm_put_lock In gdlm_put_lock(), there is a small window of time in which the DFL_UNMOUNT flag has been set but the lockspace hasn't been released, yet. In that window, dlm may still call gdlm_ast() and gdlm_bast(). To prevent it from dereferencing freed glock objects, only free the glock if the lockspace has actually been released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40083", "url": "https://ubuntu.com/security/CVE-2025-40083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: Fix null-deref in agg_dequeue To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c. To avoid code duplication, the following changes are made: 1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function. 2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it. 3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40084", "url": "https://ubuntu.com/security/CVE-2025-40084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: transport_ipc: validate payload size before reading handle handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing. This is a minimal fix to guard the initial handle read.", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40220", "url": "https://ubuntu.com/security/CVE-2025-40220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: \"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40237", "url": "https://ubuntu.com/security/CVE-2025-40237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/notify: call exportfs_encode_fid with s_umount Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr. This issue was found by syzkaller. Race Condition Diagram: Thread 1 Thread 2 -------- -------- generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb) Which then leads to: [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none) [ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240 IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path. Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock. This form of fix was suggested by Amir in [1]. [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68249", "url": "https://ubuntu.com/security/CVE-2025-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: hdm_probe: Fix calling put_device() before device initialization The early error path in hdm_probe() can jump to err_free_mdev before &mdev->dev has been initialized with device_initialize(). Calling put_device(&mdev->dev) there triggers a device core WARN and ends up invoking kref_put(&kobj->kref, kobject_release) on an uninitialized kobject. In this path the private struct was only kmalloc'ed and the intended release is effectively kfree(mdev) anyway, so free it directly instead of calling put_device() on an uninitialized device. This removes the WARNING and fixes the pre-initialization error path.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40223", "url": "https://ubuntu.com/security/CVE-2025-40223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: Fix use-after-free in hdm_disconnect hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing. The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts). Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface(). This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40106", "url": "https://ubuntu.com/security/CVE-2025-40106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: fix divide-by-zero in comedi_buf_munge() The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands.", "cve_priority": "medium", "cve_public_date": "2025-10-31 10:15:00 UTC" }, { "cve": "CVE-2025-40226", "url": "https://ubuntu.com/security/CVE-2025-40226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Account for failed debug initialization When the SCMI debug subsystem fails to initialize, the related debug root will be missing, and the underlying descriptor will be NULL. Handle this fault condition in the SCMI debug helpers that maintain metrics counters.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40231", "url": "https://ubuntu.com/security/CVE-2025-40231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix lock inversion in vsock_assign_transport() Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called. The issue was introduced by commit 687aa0c5581b (\"vsock: Fix transport_* TOCTOU\") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created. Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40233", "url": "https://ubuntu.com/security/CVE-2025-40233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: clear extent cache after moving/defragmenting extents The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters(). The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40346", "url": "https://ubuntu.com/security/CVE-2025-40346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arch_topology: Fix incorrect error check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: \"The error code within @ptr if it is an error pointer; 0 otherwise.\" This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40240", "url": "https://ubuntu.com/security/CVE-2025-40240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid NULL dereference when chunk data buffer is missing chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only. chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40350", "url": "https://ubuntu.com/security/CVE-2025-40350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run. Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it. To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40347", "url": "https://ubuntu.com/security/CVE-2025-40347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: fix the deadlock of enetc_mdio_lock After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock: enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdio After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang. Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40243", "url": "https://ubuntu.com/security/CVE-2025-40243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits() The syzbot reported issue in hfs_find_set_zero_bits(): ===================================================== BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408 hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353 __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151 block_write_begin fs/buffer.c:2262 [inline] cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 cont_expand_zero fs/buffer.c:2528 [inline] cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654 notify_change+0x1993/0x1aa0 fs/attr.c:552 do_truncate+0x28f/0x310 fs/open.c:68 do_ftruncate+0x698/0x730 fs/open.c:195 do_sys_ftruncate fs/open.c:210 [inline] __do_sys_ftruncate fs/open.c:215 [inline] __se_sys_ftruncate fs/open.c:213 [inline] __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213 x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354 kmalloc_noprof include/linux/slab.h:905 [inline] hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337 get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681 get_tree_bdev+0x38/0x50 fs/super.c:1704 hfs_get_tree+0x35/0x40 fs/hfs/super.c:388 vfs_get_tree+0xb0/0x5c0 fs/super.c:1804 do_new_mount+0x738/0x1610 fs/namespace.c:3902 path_mount+0x6db/0x1e90 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427 x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 ===================================================== The HFS_SB(sb)->bitmap buffer is allocated in hfs_mdb_get(): HFS_SB(sb)->bitmap = kmalloc(8192, GFP_KERNEL); Finally, it can trigger the reported issue because kmalloc() doesn't clear the allocated memory. If allocated memory contains only zeros, then everything will work pretty fine. But if the allocated memory contains the \"garbage\", then it can affect the bitmap operations and it triggers the reported issue. This patch simply exchanges the kmalloc() on kzalloc() with the goal to guarantee the correctness of bitmap operations. Because, newly created allocation bitmap should have all available blocks free. Potentially, initialization bitmap's read operation could not fill the whole allocated memory and \"garbage\" in the not initialized memory will be the reason of volume coruptions and file system driver bugs.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40351", "url": "https://ubuntu.com/security/CVE-2025-40351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat() The syzbot reported issue in hfsplus_delete_cat(): [ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] __se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40349", "url": "https://ubuntu.com/security/CVE-2025-40349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: validate record offset in hfsplus_bmap_alloc hfsplus_bmap_alloc can trigger a crash if a record offset or length is larger than node_size [ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0 [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183 [ 15.265949] [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary) [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 15.266167] Call Trace: [ 15.266168] [ 15.266169] dump_stack_lvl+0x53/0x70 [ 15.266173] print_report+0xd0/0x660 [ 15.266181] kasan_report+0xce/0x100 [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0 [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0 [ 15.266217] hfsplus_brec_insert+0x870/0xb00 [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570 [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910 [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200 [ 15.266233] hfsplus_file_extend+0x5a7/0x1000 [ 15.266237] hfsplus_get_block+0x12b/0x8c0 [ 15.266238] __block_write_begin_int+0x36b/0x12c0 [ 15.266251] block_write_begin+0x77/0x110 [ 15.266252] cont_write_begin+0x428/0x720 [ 15.266259] hfsplus_write_begin+0x51/0x100 [ 15.266262] cont_write_begin+0x272/0x720 [ 15.266270] hfsplus_write_begin+0x51/0x100 [ 15.266274] generic_perform_write+0x321/0x750 [ 15.266285] generic_file_write_iter+0xc3/0x310 [ 15.266289] __kernel_write_iter+0x2fd/0x800 [ 15.266296] dump_user_range+0x2ea/0x910 [ 15.266301] elf_core_dump+0x2a94/0x2ed0 [ 15.266320] vfs_coredump+0x1d85/0x45e0 [ 15.266349] get_signal+0x12e3/0x1990 [ 15.266357] arch_do_signal_or_restart+0x89/0x580 [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110 [ 15.266364] asm_exc_page_fault+0x26/0x30 [ 15.266366] RIP: 0033:0x41bd35 [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283 [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000 [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100 [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000 [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000 [ 15.266376] When calling hfsplus_bmap_alloc to allocate a free node, this function first retrieves the bitmap from header node and map node using node->page together with the offset and length from hfs_brec_lenoff ``` len = hfs_brec_lenoff(node, 2, &off16); off = off16; off += node->page_offset; pagep = node->page + (off >> PAGE_SHIFT); data = kmap_local_page(*pagep); ``` However, if the retrieved offset or length is invalid(i.e. exceeds node_size), the code may end up accessing pages outside the allocated range for this node. This patch adds proper validation of both offset and length before use, preventing out-of-bounds page access. Move is_bnode_offset_valid and check_and_correct_requested_length to hfsplus_fs.h, as they may be required by other functions.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40244", "url": "https://ubuntu.com/security/CVE-2025-40244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() The syzbot reported issue in __hfsplus_ext_cache_extent(): [ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0 [ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.196959][ T9350] cont_write_begin+0x1000/0x1950 [ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.199393][ T9350] vfs_write+0xb0f/0x14e0 [ 70.199771][ T9350] ksys_write+0x23e/0x490 [ 70.200149][ T9350] __x64_sys_write+0x97/0xf0 [ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.202054][ T9350] [ 70.202279][ T9350] Uninit was created at: [ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80 [ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0 [ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0 [ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.205074][ T9350] cont_write_begin+0x1000/0x1950 [ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.207552][ T9350] vfs_write+0xb0f/0x14e0 [ 70.207961][ T9350] ksys_write+0x23e/0x490 [ 70.208375][ T9350] __x64_sys_write+0x97/0xf0 [ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.210230][ T9350] [ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5 [ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.212115][ T9350] ===================================================== [ 70.212734][ T9350] Disabling lock debugging due to kernel taint [ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ... [ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5 [ 70.214679][ T9350] Tainted: [B]=BAD_PAGE [ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.215999][ T9350] Call Trace: [ 70.216309][ T9350] [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0 [ 70.217025][ T9350] dump_stack+0x1e/0x30 [ 70.217421][ T9350] panic+0x502/0xca0 [ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ... kernel :[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 set ... [ 70.221254][ T9350] ? __msan_warning+0x96/0x120 [ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0 [ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0 [ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0 [ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950 [ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130 [ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060 [ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460 [ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0 [ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0 [ 70.228997][ T9350] ? ksys_write+0x23e/0x490 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40245", "url": "https://ubuntu.com/security/CVE-2025-40245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nios2: ensure that memblock.current_limit is set when setting pfn limits On nios2, with CONFIG_FLATMEM set, the kernel relies on memblock_get_current_limit() to determine the limits of mem_map, in particular for max_low_pfn. Unfortunately, memblock.current_limit is only default initialized to MEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading to situations where max_low_pfn can erroneously exceed the value of max_pfn and, thus, the valid range of available DRAM. This can in turn cause kernel-level paging failures, e.g.: [ 76.900000] Unable to handle kernel paging request at virtual address 20303000 [ 76.900000] ea = c0080890, ra = c000462c, cause = 14 [ 76.900000] Kernel panic - not syncing: Oops [ 76.900000] ---[ end Kernel panic - not syncing: Oops ]--- This patch fixes this by pre-calculating memblock.current_limit based on the upper limits of the available memory ranges via adjust_lowmem_bounds, a simplified version of the equivalent implementation within the arm architecture.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40105", "url": "https://ubuntu.com/security/CVE-2025-40105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: Don't leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (\"VFS: don't keep disconnected dentries on d_anon\") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are \"leaked\". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous \"Busy inodes after unmount\" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40092", "url": "https://ubuntu.com/security/CVE-2025-40092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Refactor bind path to use __free() After an bind/unbind cycle, the ncm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40101", "url": "https://ubuntu.com/security/CVE-2025-40101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST At the end of btrfs_load_block_group_zone_info() the first thing we do is to ensure that if the mapping type is not a SINGLE one and there is no RAID stripe tree, then we return early with an error. Doing that, though, prevents the code from running the last calls from this function which are about freeing memory allocated during its run. Hence, in this case, instead of returning early, we set the ret value and fall through the rest of the cleanup code.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40166", "url": "https://ubuntu.com/security/CVE-2025-40166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Check GuC running state before deregistering exec queue In normal operation, a registered exec queue is disabled and deregistered through the GuC, and freed only after the GuC confirms completion. However, if the driver is forced to unbind while the exec queue is still running, the user may call exec_destroy() after the GuC has already been stopped and CT communication disabled. In this case, the driver cannot receive a response from the GuC, preventing proper cleanup of exec queue resources. Fix this by directly releasing the resources when GuC is not running. Here is the failure dmesg log: \" [ 468.089581] ---[ end trace 0000000000000000 ]--- [ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535) [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535 [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1 [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1) [ 468.092716] ------------[ cut here ]------------ [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe] \" v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled(). As CT may go down and come back during VF migration. (cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40104", "url": "https://ubuntu.com/security/CVE-2025-40104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ixgbevf: fix mailbox API compatibility by negotiating supported features There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API. This convention has been broken since introducing API 1.4. Commit 0062e7cc955e (\"ixgbevf: add VF IPsec offload code\") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself. Commit 339f28964147 (\"ixgbevf: Add support for new mailbox communication between PF and VF\") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes. The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 (\"ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5\"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX. To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox. New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op. Features negotiation mechanism gives possibility to be extended with new features when needed in the future.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40087", "url": "https://ubuntu.com/security/CVE-2025-40087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Define a proc_layoutcommit for the FlexFiles layout type Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40196", "url": "https://ubuntu.com/security/CVE-2025-40196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to \"events_unbound\" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance \"writeback\" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40088", "url": "https://ubuntu.com/security/CVE-2025-40088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp() The hfsplus_strcasecmp() logic can trigger the issue: [ 117.317703][ T9855] ================================================================== [ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490 [ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855 [ 117.319577][ T9855] [ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full) [ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 117.319783][ T9855] Call Trace: [ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0 [ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10 [ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0 [ 117.319816][ T9855] ? lock_release+0x4b/0x3e0 [ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40 [ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319842][ T9855] print_report+0x17e/0x7e0 [ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319862][ T9855] ? __phys_addr+0xd3/0x180 [ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319876][ T9855] kasan_report+0x147/0x180 [ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490 [ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10 [ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0 [ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470 [ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10 [ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10 [ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510 [ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10 [ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510 [ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0 [ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120 [ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890 [ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10 [ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0 [ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80 [ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10 [ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100 [ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150 [ 117.320034][ T9855] __lookup_slow+0x297/0x3d0 [ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10 [ 117.320045][ T9855] ? down_read+0x1ad/0x2e0 [ 117.320055][ T9855] lookup_slow+0x53/0x70 [ 117.320065][ T9855] walk_component+0x2f0/0x430 [ 117.320073][ T9855] path_lookupat+0x169/0x440 [ 117.320081][ T9855] filename_lookup+0x212/0x590 [ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10 [ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290 [ 117.320105][ T9855] ? getname_flags+0x1e5/0x540 [ 117.320112][ T9855] user_path_at+0x3a/0x60 [ 117.320117][ T9855] __x64_sys_umount+0xee/0x160 [ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10 [ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0 [ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0 [ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0 [ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07 [ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08 [ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40085", "url": "https://ubuntu.com/security/CVE-2025-40085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card In try_to_register_card(), the return value of usb_ifnum_to_if() is passed directly to usb_interface_claimed() without a NULL check, which will lead to a NULL pointer dereference when creating an invalid USB audio device. Fix this by adding a check to ensure the interface pointer is valid before passing it to usb_interface_claimed().", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40172", "url": "https://ubuntu.com/security/CVE-2025-40172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() Currently, if find_and_map_user_pages() takes a DMA xfer request from the user with a length field set to 0, or in a rare case, the host receives QAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size is equal to the requested transaction size, the function will return 0 before allocating an sgt or setting the fields of the dma_xfer struct. In that case, encode_addr_size_pairs() will try to access the sgt which will lead to a general protection fault. Return an EINVAL in case the user provides a zero-sized ALP, or the device requests continuation after all of the bytes have been transferred.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40176", "url": "https://ubuntu.com/security/CVE-2025-40176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: wait for pending async decryptions if tls_strp_msg_hold fails Async decryption calls tls_strp_msg_hold to create a clone of the input skb to hold references to the memory it uses. If we fail to allocate that clone, proceeding with async decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, wait for all pending decryption requests.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40173", "url": "https://ubuntu.com/security/CVE-2025-40173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ip6_tunnel: Prevent perpetual tunnel growth Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd (\"net: ip_tunnel: prevent perpetual headroom growth\"), ipv6 tunnel yet increases the headroom without any ceiling. Reflect ipv4 tunnel headroom adjustment limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-specific patch and a reproducer.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40095", "url": "https://ubuntu.com/security/CVE-2025-40095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Refactor bind path to use __free() After an bind/unbind cycle, the rndis->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40094", "url": "https://ubuntu.com/security/CVE-2025-40094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_acm: Refactor bind path to use __free() After an bind/unbind cycle, the acm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec gs_free_req+0x30/0x44 acm_bind+0x1b8/0x1f4 usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40093", "url": "https://ubuntu.com/security/CVE-2025-40093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ecm: Refactor bind path to use __free() After an bind/unbind cycle, the ecm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40165", "url": "https://ubuntu.com/security/CVE-2025-40165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: m2m: Fix streaming cleanup on release If streamon/streamoff calls are imbalanced, such as when exiting an application with Ctrl+C when streaming, the m2m usage_count will never reach zero and the ISI channel won't be freed. Besides from that, if the input line width is more than 2K, it will trigger a WARN_ON(): [ 59.222120] ------------[ cut here ]------------ [ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654 [ 59.238569] Modules linked in: ap1302 [ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT [ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT) [ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120 [ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120 [ 59.275047] sp : ffff8000848c3b40 [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00 [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001 [ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780 [ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000 [ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c [ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30 [ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420 [ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000 [ 59.349590] Call trace: [ 59.352025] mxc_isi_channel_chain+0xa4/0x120 (P) [ 59.356722] mxc_isi_m2m_streamon+0x160/0x20c [ 59.361072] v4l_streamon+0x24/0x30 [ 59.364556] __video_do_ioctl+0x40c/0x4a0 [ 59.368560] video_usercopy+0x2bc/0x690 [ 59.372382] video_ioctl2+0x18/0x24 [ 59.375857] v4l2_ioctl+0x40/0x60 [ 59.379168] __arm64_sys_ioctl+0xac/0x104 [ 59.383172] invoke_syscall+0x48/0x104 [ 59.386916] el0_svc_common.constprop.0+0xc0/0xe0 [ 59.391613] do_el0_svc+0x1c/0x28 [ 59.394915] el0_svc+0x34/0xf4 [ 59.397966] el0t_64_sync_handler+0xa0/0xe4 [ 59.402143] el0t_64_sync+0x198/0x19c [ 59.405801] ---[ end trace 0000000000000000 ]--- Address this issue by moving the streaming preparation and cleanup to the vb2 .prepare_streaming() and .unprepare_streaming() operations. This also simplifies the driver by allowing direct usage of the v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40096", "url": "https://ubuntu.com/security/CVE-2025-40096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free. Interestingly this bug appears to have been present ever since commit ebd5f74255b9 (\"drm/sched: Add dependency tracking\"), since the code back then looked like this: drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]); Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it. The bug was then only noticed and fixed after commit 9c2ba265352a (\"drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2\") landed, with its fixup of commit 4eaf02d6076c (\"drm/scheduler: fix drm_sched_job_add_implicit_dependencies\"). At that point it was a slightly different flavour of a double free, which commit 963d0b356935 (\"drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder\") noticed and attempted to fix. But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case. As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain. While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.", "cve_priority": "low", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40099", "url": "https://ubuntu.com/security/CVE-2025-40099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: parse_dfs_referrals: prevent oob on malformed input Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS - reply smaller than sizeof(struct get_dfs_referral_rsp) - reply with number of referrals smaller than NumberOfReferrals in the header Processing of such replies will cause oob. Return -EINVAL error on such replies to prevent oob-s.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40100", "url": "https://ubuntu.com/security/CVE-2025-40100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40167", "url": "https://ubuntu.com/security/CVE-2025-40167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: detect invalid INLINE_DATA + EXTENTS flag combination syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal. The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 This is an invalid combination since an inode should have either: - INLINE_DATA: data stored directly in the inode - EXTENTS: data stored in extent-mapped blocks Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40198", "url": "https://ubuntu.com/security/CVE-2025-40198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40159", "url": "https://ubuntu.com/security/CVE-2025-40159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Harden userspace-supplied xdp_desc validation Turned out certain clearly invalid values passed in xdp_desc from userspace can pass xp_{,un}aligned_validate_desc() and then lead to UBs or just invalid frames to be queued for xmit. desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len can cause positive integer overflow and wraparound, the same way low enough desc->addr with a non-zero pool->tx_metadata_len can cause negative integer overflow. Both scenarios can then pass the validation successfully. This doesn't happen with valid XSk applications, but can be used to perform attacks. Always promote desc->len to ``u64`` first to exclude positive overflows of it. Use explicit check_{add,sub}_overflow() when validating desc->addr (which is ``u64`` already). bloat-o-meter reports a little growth of the code size: add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44) Function old new delta xskq_cons_peek_desc 299 330 +31 xsk_tx_peek_release_desc_batch 973 1002 +29 xsk_generic_xmit 3148 3132 -16 but hopefully this doesn't hurt the performance much.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40221", "url": "https://ubuntu.com/security/CVE-2025-40221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: mg4b: fix uninitialized iio scan data Fix potential leak of uninitialized stack data to userspace by ensuring that the `scan` structure is zeroed before use.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40180", "url": "https://ubuntu.com/security/CVE-2025-40180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40178", "url": "https://ubuntu.com/security/CVE-2025-40178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pid: Add a judgment for ns null in pid_nr_ns __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: \tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058 \tMem abort info: \tESR = 0x0000000096000007 \tEC = 0x25: DABT (current EL), IL = 32 bits \tSET = 0, FnV = 0 \tEA = 0, S1PTW = 0 \tFSC = 0x07: level 3 translation fault \tData abort info: \tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 \tCM = 0, WnR = 0, TnD = 0, TagAccess = 0 \tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 \t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 \tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) \tpc : __task_pid_nr_ns+0x74/0xd0 \tlr : __task_pid_nr_ns+0x24/0xd0 \tsp : ffffffc08001bd10 \tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 \tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 \tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 \tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 \tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc \tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 \tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 \tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 \tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc \tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 \tCall trace: \t__task_pid_nr_ns+0x74/0xd0 \t... \t__handle_irq_event_percpu+0xd4/0x284 \thandle_irq_event+0x48/0xb0 \thandle_fasteoi_irq+0x160/0x2d8 \tgeneric_handle_domain_irq+0x44/0x60 \tgic_handle_irq+0x4c/0x114 \tcall_on_irq_stack+0x3c/0x74 \tdo_interrupt_handler+0x4c/0x84 \tel1_interrupt+0x34/0x58 \tel1h_64_irq_handler+0x18/0x24 \tel1h_64_irq+0x68/0x6c \taccount_kernel_stack+0x60/0x144 \texit_task_stack_account+0x1c/0x80 \tdo_exit+0x7e4/0xaf8 \t... \tget_signal+0x7bc/0x8d8 \tdo_notify_resume+0x128/0x828 \tel0_svc+0x6c/0x70 \tel0t_64_sync_handler+0x68/0xbc \tel0t_64_sync+0x1a8/0x1ac \tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) \t---[ end trace 0000000000000000 ]--- \tKernel panic - not syncing: Oops: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40202", "url": "https://ubuntu.com/security/CVE-2025-40202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Rework user message limit handling The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free. Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine. It's a lot cleaner and safer.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40032", "url": "https://ubuntu.com/security/CVE-2025-40032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 [mani: trimmed the stack trace]", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40038", "url": "https://ubuntu.com/security/CVE-2025-40038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b Note, this is essentially a reapply of commit 5c30e8101e8d (\"KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid\"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons).", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40042", "url": "https://ubuntu.com/security/CVE-2025-40042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race condition in kprobe initialization causing NULL pointer dereference There is a critical race condition in kprobe initialization that can lead to NULL pointer dereference and kernel crash. [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000 ... [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO) [1135630.269239] pc : kprobe_perf_func+0x30/0x260 [1135630.277643] lr : kprobe_dispatcher+0x44/0x60 [1135630.286041] sp : ffffaeff4977fa40 [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400 [1135630.302837] x27: 0000000000000000 x26: 0000000000000000 [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528 [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50 [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50 [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000 [1135630.349985] x17: 0000000000000000 x16: 0000000000000000 [1135630.359285] x15: 0000000000000000 x14: 0000000000000000 [1135630.368445] x13: 0000000000000000 x12: 0000000000000000 [1135630.377473] x11: 0000000000000000 x10: 0000000000000000 [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000 [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000 [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000 [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006 [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000 [1135630.429410] Call trace: [1135630.434828] kprobe_perf_func+0x30/0x260 [1135630.441661] kprobe_dispatcher+0x44/0x60 [1135630.448396] aggr_pre_handler+0x70/0xc8 [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0 [1135630.462435] brk_handler+0xbc/0xd8 [1135630.468437] do_debug_exception+0x84/0x138 [1135630.475074] el1_dbg+0x18/0x8c [1135630.480582] security_file_permission+0x0/0xd0 [1135630.487426] vfs_write+0x70/0x1c0 [1135630.493059] ksys_write+0x5c/0xc8 [1135630.498638] __arm64_sys_write+0x24/0x30 [1135630.504821] el0_svc_common+0x78/0x130 [1135630.510838] el0_svc_handler+0x38/0x78 [1135630.516834] el0_svc+0x8/0x1b0 kernel/trace/trace_kprobe.c: 1308 0xffff3df8995039ec : ldr x21, [x24,#120] include/linux/compiler.h: 294 0xffff3df8995039f0 : ldr x1, [x21,x0] kernel/trace/trace_kprobe.c 1308: head = this_cpu_ptr(call->perf_events); 1309: if (hlist_empty(head)) 1310: \treturn 0; crash> struct trace_event_call -o struct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ... } crash> struct trace_event_call ffffaf015340e528 struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ... } Race Condition Analysis: The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)← KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL) Problem: 1. CPU0 executes (1) assigning tp_event->perf_events = list 2. CPU0 executes (2) enabling kprobe functionality via class->reg() 3. CPU1 triggers and reaches kprobe_dispatcher 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed) 5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULL CPU1 sees that kprobe functionality is enabled but does not see that perf_events has been assigned. Add pairing read an ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40200", "url": "https://ubuntu.com/security/CVE-2025-40200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: reject negative file sizes in squashfs_read_inode() Syskaller reports a \"WARNING in ovl_copy_up_file\" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip@squashfs.org.uk: only need to check 64 bit quantity]", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40179", "url": "https://ubuntu.com/security/CVE-2025-40179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: verify orphan file size is not too big In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but large orphan files.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40218", "url": "https://ubuntu.com/security/CVE-2025-40218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr: do not repeat pte_offset_map_lock() until success DAMON's virtual address space operation set implementation (vaddr) calls pte_offset_map_lock() inside the page table walk callback function. This is for reading and writing page table accessed bits. If pte_offset_map_lock() fails, it retries by returning the page table walk callback function with ACTION_AGAIN. pte_offset_map_lock() can continuously fail if the target is a pmd migration entry, though. Hence it could cause an infinite page table walk if the migration cannot be done until the page table walk is finished. This indeed caused a soft lockup when CPU hotplugging and DAMON were running in parallel. Avoid the infinite loop by simply not retrying the page table walk. DAMON is promising only a best-effort accuracy, so missing access to such pages is no problem.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40219", "url": "https://ubuntu.com/security/CVE-2025-40219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 (\"PCI: Add global pci_lock_rescan_remove()\") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc (\"PCI/IOV: Factor out sriov_add_vfs()\") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 \t00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 \t0000000000000001 0000000000000000 0000000000000000 0000000180692828 \t00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40193", "url": "https://ubuntu.com/security/CVE-2025-40193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xtensa: simdisk: add input size check in proc_write_simdisk A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash. This follows the same pattern as commit ee76746387f6 (\"netdevsim: prevent bad user input in nsim_dev_health_break_write()\")", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40204", "url": "https://ubuntu.com/security/CVE-2025-40204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40192", "url": "https://ubuntu.com/security/CVE-2025-40192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"ipmi: fix msg stack when IPMI is disconnected\" This reverts commit c608966f3f9c2dca596967501d00753282b395fc. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40188", "url": "https://ubuntu.com/security/CVE-2025-40188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pwm: berlin: Fix wrong register in suspend/resume The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40201", "url": "https://ubuntu.com/security/CVE-2025-40201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40194", "url": "https://ubuntu.com/security/CVE-2025-40194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40205", "url": "https://ubuntu.com/security/CVE-2025-40205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid potential out-of-bounds in btrfs_encode_fh() The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40160", "url": "https://ubuntu.com/security/CVE-2025-40160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/events: Return -EEXIST for bound VIRQs Change find_virq() to return -EEXIST when a VIRQ is bound to a different CPU than the one passed in. With that, remove the BUG_ON() from bind_virq_to_irq() to propogate the error upwards. Some VIRQs are per-cpu, but others are per-domain or global. Those must be bound to CPU0 and can then migrate elsewhere. The lookup for per-domain and global will probably fail when migrated off CPU 0, especially when the current CPU is tracked. This now returns -EEXIST instead of BUG_ON(). A second call to bind a per-domain or global VIRQ is not expected, but make it non-fatal to avoid trying to look up the irq, since we don't know which per_cpu(virq_to_irq) it will be in.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40206", "url": "https://ubuntu.com/security/CVE-2025-40206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_objref: validate objref and objrefmap expressions Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls: BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12) [...] Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 [...] Implement objref and objrefmap expression validate functions. Currently, only NFT_OBJECT_SYNPROXY object type requires validation. This will also handle a jump to a chain using a synproxy object from the OUTPUT hook. Now when trying to reference a synproxy object in the OUTPUT hook, nft will produce the following error: synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40183", "url": "https://ubuntu.com/security/CVE-2025-40183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6} Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40187", "url": "https://ubuntu.com/security/CVE-2025-40187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40111", "url": "https://ubuntu.com/security/CVE-2025-40111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix Use-after-free in validation Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.", "cve_priority": "medium", "cve_public_date": "2025-11-12 02:15:00 UTC" }, { "cve": "CVE-2025-40110", "url": "https://ubuntu.com/security/CVE-2025-40110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a null-ptr access in the cursor snooper Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it. vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean \"no surface\", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it. Fixes unchecked null-ptr reference in the snooping code.", "cve_priority": "medium", "cve_public_date": "2025-11-12 02:15:00 UTC" }, { "cve": "CVE-2025-40001", "url": "https://ubuntu.com/security/CVE-2025-40001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mvsas: Fix use-after-free bugs in mvs_work_queue During the detaching of Marvell's SAS/SATA controller, the original code calls cancel_delayed_work() in mvs_free() to cancel the delayed work item mwq->work_q. However, if mwq->work_q is already running, the cancel_delayed_work() may fail to cancel it. This can lead to use-after-free scenarios where mvs_free() frees the mvs_info while mvs_work_queue() is still executing and attempts to access the already-freed mvs_info. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work item completes before the mvs_info is deallocated. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2025-10-18 08:15:00 UTC" }, { "cve": "CVE-2025-40207", "url": "https://ubuntu.com/security/CVE-2025-40207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try() v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40031", "url": "https://ubuntu.com/security/CVE-2025-40031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: fix register_shm_helper() In register_shm_helper(), fix incorrect error handling for a call to iov_iter_extract_pages(). A case is missing for when iov_iter_extract_pages() only got some pages and return a number larger than 0, but not the requested amount. This fixes a possible NULL pointer dereference following a bad input from ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40037", "url": "https://ubuntu.com/security/CVE-2025-40037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: simplefb: Fix use after free in simplefb_detach_genpds() The pm_domain cleanup can not be devres managed as it uses struct simplefb_par which is allocated within struct fb_info by framebuffer_alloc(). This allocation is explicitly freed by unregister_framebuffer() in simplefb_remove(). Devres managed cleanup runs after the device remove call and thus can no longer access struct simplefb_par. Call simplefb_detach_genpds() explicitly from simplefb_destroy() like the cleanup functions for clocks and regulators. Fixes an use after free on M2 Mac mini during aperture_remove_conflicting_devices() using the downstream asahi kernel with Debian's kernel config. For unknown reasons this started to consistently dereference an invalid pointer in v6.16.3 based kernels. [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220 [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227 [ 6.750697] [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT) [ 6.752189] Call trace: [ 6.752190] show_stack+0x34/0x98 (C) [ 6.752194] dump_stack_lvl+0x60/0x80 [ 6.752197] print_report+0x17c/0x4d8 [ 6.752201] kasan_report+0xb4/0x100 [ 6.752206] __asan_report_load4_noabort+0x20/0x30 [ 6.752209] simplefb_detach_genpds+0x58/0x220 [ 6.752213] devm_action_release+0x50/0x98 [ 6.752216] release_nodes+0xd0/0x2c8 [ 6.752219] devres_release_all+0xfc/0x178 [ 6.752221] device_unbind_cleanup+0x28/0x168 [ 6.752224] device_release_driver_internal+0x34c/0x470 [ 6.752228] device_release_driver+0x20/0x38 [ 6.752231] bus_remove_device+0x1b0/0x380 [ 6.752234] device_del+0x314/0x820 [ 6.752238] platform_device_del+0x3c/0x1e8 [ 6.752242] platform_device_unregister+0x20/0x50 [ 6.752246] aperture_detach_platform_device+0x1c/0x30 [ 6.752250] aperture_detach_devices+0x16c/0x290 [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50 ... [ 6.752343] [ 6.967409] Allocated by task 62: [ 6.970724] kasan_save_stack+0x3c/0x70 [ 6.974560] kasan_save_track+0x20/0x40 [ 6.978397] kasan_save_alloc_info+0x40/0x58 [ 6.982670] __kasan_kmalloc+0xd4/0xd8 [ 6.986420] __kmalloc_noprof+0x194/0x540 [ 6.990432] framebuffer_alloc+0xc8/0x130 [ 6.994444] simplefb_probe+0x258/0x2378 ... [ 7.054356] [ 7.055838] Freed by task 227: [ 7.058891] kasan_save_stack+0x3c/0x70 [ 7.062727] kasan_save_track+0x20/0x40 [ 7.066565] kasan_save_free_info+0x4c/0x80 [ 7.070751] __kasan_slab_free+0x6c/0xa0 [ 7.074675] kfree+0x10c/0x380 [ 7.077727] framebuffer_release+0x5c/0x90 [ 7.081826] simplefb_destroy+0x1b4/0x2c0 [ 7.085837] put_fb_info+0x98/0x100 [ 7.089326] unregister_framebuffer+0x178/0x320 [ 7.093861] simplefb_remove+0x3c/0x60 [ 7.097611] platform_remove+0x60/0x98 [ 7.101361] device_remove+0xb8/0x160 [ 7.105024] device_release_driver_internal+0x2fc/0x470 [ 7.110256] device_release_driver+0x20/0x38 [ 7.114529] bus_remove_device+0x1b0/0x380 [ 7.118628] device_del+0x314/0x820 [ 7.122116] platform_device_del+0x3c/0x1e8 [ 7.126302] platform_device_unregister+0x20/0x50 [ 7.131012] aperture_detach_platform_device+0x1c/0x30 [ 7.136157] aperture_detach_devices+0x16c/0x290 [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50 ...", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40047", "url": "https://ubuntu.com/security/CVE-2025-40047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: always prune wait queue entry in io_waitid_wait() For a successful return, always remove our entry from the wait queue entry list. Previously this was skipped if a cancelation was in progress, but this can race with another invocation of the wait queue entry callback.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40057", "url": "https://ubuntu.com/security/CVE-2025-40057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Add a upper bound on max_vclocks syzbot reported WARNING in max_vclocks_store. This occurs when the argument max is too large for kcalloc to handle. Extend the guard to guard against values that are too large for kcalloc", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40058", "url": "https://ubuntu.com/security/CVE-2025-40058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Disallow dirty tracking if incoherent page walk Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work. The Intel VT-d specification, Section 3.10 \"Snoop Behavior\" states: \"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault.\" To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40059", "url": "https://ubuntu.com/security/CVE-2025-40059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: Fix incorrect handling for return value of devm_kzalloc The return value of devm_kzalloc could be an null pointer, use \"!desc.pdata\" to fix incorrect handling return value of devm_kzalloc.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40155", "url": "https://ubuntu.com/security/CVE-2025-40155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: debugfs: Fix legacy mode page table dump logic In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490 ... Avoid walking the page table if TT is not 00b or 01b.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40079", "url": "https://ubuntu.com/security/CVE-2025-40079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Sign extend struct ops return values properly The ns_bpf_qdisc selftest triggers a kernel panic: Unable to handle kernel paging request at virtual address ffffffffa38dbf58 Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000 [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000 Oops [#1] Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)] CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G W OE 6.17.0-rc1-g2465bb83e0b4 #1 NONE Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024 epc : __qdisc_run+0x82/0x6f0 ra : __qdisc_run+0x6e/0x6f0 epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550 gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180 t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0 s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001 a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000 a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049 s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000 s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0 s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000 s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000 t5 : 0000000000000000 t6 : ff60000093a6a8b6 status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d [] __qdisc_run+0x82/0x6f0 [] __dev_queue_xmit+0x4c0/0x1128 [] neigh_resolve_output+0xd0/0x170 [] ip6_finish_output2+0x226/0x6c8 [] ip6_finish_output+0x10c/0x2a0 [] ip6_output+0x5e/0x178 [] ip6_xmit+0x29a/0x608 [] inet6_csk_xmit+0xe6/0x140 [] __tcp_transmit_skb+0x45c/0xaa8 [] tcp_connect+0x9ce/0xd10 [] tcp_v6_connect+0x4ac/0x5e8 [] __inet_stream_connect+0xd8/0x318 [] inet_stream_connect+0x3e/0x68 [] __sys_connect_file+0x50/0x88 [] __sys_connect+0x96/0xc8 [] __riscv_sys_connect+0x20/0x30 [] do_trap_ecall_u+0x256/0x378 [] handle_exception+0x14a/0x156 Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709 ---[ end trace 0000000000000000 ]--- The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires RISC-V ABI. So let's sign extend struct ops return values according to the function model and RISC-V ABI([0]). [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40000", "url": "https://ubuntu.com/security/CVE-2025-40000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait() There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to access already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 It is a consequence of a race between the waiting and the signaling side of the completion: Waiting thread Completing thread rtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40026", "url": "https://ubuntu.com/security/CVE-2025-40026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended \"recipient\") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-10-28 10:15:00 UTC" }, { "cve": "CVE-2025-40027", "url": "https://ubuntu.com/security/CVE-2025-40027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix double req put in p9_fd_cancelled Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__list_del_entry include/linux/list.h:137 [inline] RIP: 0010:list_del include/linux/list.h:148 [inline] RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734 Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ... Commit 74d6a5d56629 (\"9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work\") fixes a concurrency issue in the 9p filesystem client where the req_list could be deleted simultaneously by both p9_read_work and p9_fd_cancelled functions, but for the case where req->status equals REQ_STATUS_RCVD. Update the check for req->status in p9_fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [updated the check from status == RECV || status == ERROR to status != SENT]", "cve_priority": "medium", "cve_public_date": "2025-10-28 10:15:00 UTC" }, { "cve": "CVE-2025-40109", "url": "https://ubuntu.com/security/CVE-2025-40109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present Ensure that set_ent is always set since only drbg provides it.", "cve_priority": "medium", "cve_public_date": "2025-11-09 05:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40107", "url": "https://ubuntu.com/security/CVE-2025-40107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d (\"can: mcp251x: fix resume from sleep before interface was brought up\"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-11-03 13:15:00 UTC" }, { "cve": "CVE-2025-39995", "url": "https://ubuntu.com/security/CVE-2025-39995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe The state->timer is a cyclic timer that schedules work_i2c_poll and delayed_work_enable_hotplug, while rearming itself. Using timer_delete() fails to guarantee the timer isn't still running when destroyed, similarly cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has terminated if already executing. During probe failure after timer initialization, these may continue running as orphans and reference the already-freed tc358743_state object through tc358743_irq_poll_timer. The following is the trace captured by KASAN. BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace timer_delete() with timer_delete_sync() and cancel_delayed_work() with cancel_delayed_work_sync() to ensure proper termination of timer and work items before resource cleanup. This bug was initially identified through static analysis. For reproduction and testing, I created a functional emulation of the tc358743 device via a kernel module and introduced faults through the debugfs interface.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39994", "url": "https://ubuntu.com/security/CVE-2025-39994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tuner: xc5000: Fix use-after-free in xc5000_release The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was initially identified through static analysis. [hverkuil: fix typo in Subject: tunner -> tuner]", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39991", "url": "https://ubuntu.com/security/CVE-2025-39991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39992", "url": "https://ubuntu.com/security/CVE-2025-39992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap())\t\t\tswapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> \tcopy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). \t\t\t\t 4) swapoff is tried on the \t\t\t\t\t'mm' added to the 'mmlist' as \t\t\t\t\tpart of the 2. \t\t\t\t 5) unuse_mm(), that iterates \t\t\t\t\tthrough the vma's of this 'mm' \t\t\t\t\twill hit the non-NULL zero entry \t\t\t\t\tand operating on this zero entry \t\t\t\t\tas a vma is resulting into the \t\t\t\t\toops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40013", "url": "https://ubuntu.com/security/CVE-2025-40013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: audioreach: fix potential null pointer dereference It is possible that the topology parsing function audioreach_widget_load_module_common() could return NULL or an error pointer. Add missing NULL check so that we do not dereference it.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39996", "url": "https://ubuntu.com/security/CVE-2025-39996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAF This is confirmed by a KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39998", "url": "https://ubuntu.com/security/CVE-2025-39998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: target_core_configfs: Add length check to avoid buffer overflow A buffer overflow arises from the usage of snprintf to write into the buffer \"buf\" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40009", "url": "https://ubuntu.com/security/CVE-2025-40009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: check p->vec_buf for NULL When the PAGEMAP_SCAN ioctl is invoked with vec_len = 0 reaches pagemap_scan_backout_range(), kernel panics with null-ptr-deref: [ 44.936808] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.937797] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 44.938391] CPU: 1 UID: 0 PID: 2480 Comm: reproducer Not tainted 6.17.0-rc6 #22 PREEMPT(none) [ 44.939062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.939935] RIP: 0010:pagemap_scan_thp_entry.isra.0+0x741/0xa80 [ 44.946828] Call Trace: [ 44.947030] [ 44.949219] pagemap_scan_pmd_entry+0xec/0xfa0 [ 44.952593] walk_pmd_range.isra.0+0x302/0x910 [ 44.954069] walk_pud_range.isra.0+0x419/0x790 [ 44.954427] walk_p4d_range+0x41e/0x620 [ 44.954743] walk_pgd_range+0x31e/0x630 [ 44.955057] __walk_page_range+0x160/0x670 [ 44.956883] walk_page_range_mm+0x408/0x980 [ 44.958677] walk_page_range+0x66/0x90 [ 44.958984] do_pagemap_scan+0x28d/0x9c0 [ 44.961833] do_pagemap_cmd+0x59/0x80 [ 44.962484] __x64_sys_ioctl+0x18d/0x210 [ 44.962804] do_syscall_64+0x5b/0x290 [ 44.963111] entry_SYSCALL_64_after_hwframe+0x76/0x7e vec_len = 0 in pagemap_scan_init_bounce_buffer() means no buffers are allocated and p->vec_buf remains set to NULL. This breaks an assumption made later in pagemap_scan_backout_range(), that page_region is always allocated for p->vec_buf_index. Fix it by explicitly checking p->vec_buf for NULL before dereferencing. Other sites that might run into same deref-issue are already (directly or transitively) protected by checking p->vec_buf. Note: From PAGEMAP_SCAN man page, it seems vec_len = 0 is valid when no output is requested and it's only the side effects caller is interested in, hence it passes check in pagemap_scan_get_args(). This issue was found by syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39973", "url": "https://ubuntu.com/security/CVE-2025-39973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: add validation for ring_len param The `ring_len` parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation. To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-38709", "url": "https://ubuntu.com/security/CVE-2025-38709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: loop: Avoid updating block size under exclusive owner Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39967", "url": "https://ubuntu.com/security/CVE-2025-39967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix integer overflow in fbcon_do_set_font Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters. The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying. Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40006", "url": "https://ubuntu.com/security/CVE-2025-40006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix folio is still mapped when deleted Migration may be raced with fallocating hole. remove_inode_single_folio will unmap the folio if the folio is still mapped. However, it's called without folio lock. If the folio is migrated and the mapped pte has been converted to migration entry, folio_mapped() returns false, and won't unmap it. Due to extra refcount held by remove_inode_single_folio, migration fails, restores migration entry to normal pte, and the folio is mapped again. As a result, we triggered BUG in filemap_unaccount_folio. The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):\"my_hugepage_file\" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380 Hold folio lock before checking if the folio is mapped to avold race with migration.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40008", "url": "https://ubuntu.com/security/CVE-2025-40008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kmsan: fix out-of-bounds access to shadow memory Running sha224_kunit on a KMSAN-enabled kernel results in a crash in kmsan_internal_set_shadow_origin(): BUG: unable to handle page fault for address: ffffbc3840291000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1810067 P4D 1810067 PUD 192d067 PMD 3c17067 PTE 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 81 Comm: kunit_try_catch Tainted: G N 6.17.0-rc3 #10 PREEMPT(voluntary) Tainted: [N]=TEST Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmsan_internal_set_shadow_origin+0x91/0x100 [...] Call Trace: __msan_memset+0xee/0x1a0 sha224_final+0x9e/0x350 test_hash_buffer_overruns+0x46f/0x5f0 ? kmsan_get_shadow_origin_ptr+0x46/0xa0 ? __pfx_test_hash_buffer_overruns+0x10/0x10 kunit_try_run_case+0x198/0xa00 This occurs when memset() is called on a buffer that is not 4-byte aligned and extends to the end of a guard page, i.e. the next page is unmapped. The bug is that the loop at the end of kmsan_internal_set_shadow_origin() accesses the wrong shadow memory bytes when the address is not 4-byte aligned. Since each 4 bytes are associated with an origin, it rounds the address and size so that it can access all the origins that contain the buffer. However, when it checks the corresponding shadow bytes for a particular origin, it incorrectly uses the original unrounded shadow address. This results in reads from shadow memory beyond the end of the buffer's shadow memory, which crashes when that memory is not mapped. To fix this, correctly align the shadow address before accessing the 4 shadow bytes corresponding to each origin.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40010", "url": "https://ubuntu.com/security/CVE-2025-40010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix potential null pointer dereference in afs_put_server afs_put_server() accessed server->debug_id before the NULL check, which could lead to a null pointer dereference. Move the debug_id assignment, ensuring we never dereference a NULL server pointer.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40021", "url": "https://ubuntu.com/security/CVE-2025-40021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: dynevent: Add a missing lockdown check on dynevent Since dynamic_events interface on tracefs is compatible with kprobe_events and uprobe_events, it should also check the lockdown status and reject if it is set.", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39968", "url": "https://ubuntu.com/security/CVE-2025-39968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: add max boundary check for VF filters There is no check for max filters that VF can request. Add it.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39969", "url": "https://ubuntu.com/security/CVE-2025-39969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix validation of VF state in get resources VF state I40E_VF_STATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources. Use I40E_VF_STATE_RESOURCES_LOADED that is set only in i40e_vc_get_vf_resources_msg() and cleared during reset.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39970", "url": "https://ubuntu.com/security/CVE-2025-39970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix input validation logic for action_meta Fix condition to check 'greater or equal' to prevent OOB dereference.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39971", "url": "https://ubuntu.com/security/CVE-2025-39971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39972", "url": "https://ubuntu.com/security/CVE-2025-39972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in i40e_validate_queue_map Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map().", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39977", "url": "https://ubuntu.com/security/CVE-2025-39977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent use-after-free during requeue-PI syzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL); In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization. This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section. Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated. Read futex_q::task before updating the requeue state, use it for the following wakeup.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40011", "url": "https://ubuntu.com/security/CVE-2025-40011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix null dereference in hdmi teardown pci_set_drvdata sets the value of pdev->driver_data to NULL, after which the driver_data obtained from the same dev is dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is extracted from it. To prevent this, swap these calls. Found by Linux Verification Center (linuxtesting.org) with Svacer.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39978", "url": "https://ubuntu.com/security/CVE-2025-39978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow() This code calls kfree_rcu(new_node, rcu) and then dereferences \"new_node\" and then dereferences it on the next line. Two lines later, we take a mutex so I don't think this is an RCU safe region. Re-order it to do the dereferences before queuing up the free.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39980", "url": "https://ubuntu.com/security/CVE-2025-39980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Forbid FDB status change while nexthop is in a group The kernel forbids the creation of non-FDB nexthop groups with FDB nexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops. And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops. However, as long as no routes are pointing to a non-FDB nexthop group, the kernel allows changing the type of a nexthop from FDB to non-FDB and vice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0 This configuration is invalid and can result in a NPD [1] since FDB nexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1 Fix by preventing nexthop FDB status change while the nexthop is in a group: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group. [1] BUG: kernel NULL pointer dereference, address: 00000000000003c0 [...] Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:fib_lookup_good_nhc+0x1e/0x80 [...] Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40024", "url": "https://ubuntu.com/security/CVE-2025-40024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost: Take a reference on the task in struct vhost_task. vhost_task_create() creates a task and keeps a reference to its task_struct. That task may exit early via a signal and its task_struct will be released. A pending vhost_task_wake() will then attempt to wake the task and access a task_struct which is no longer there. Acquire a reference on the task_struct while creating the thread and release the reference while the struct vhost_task itself is removed. If the task exits early due to a signal, then the vhost_task_wake() will still access a valid task_struct. The wake is safe and will be skipped in this case.", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39982", "url": "https://ubuntu.com/security/CVE-2025-39982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync This fixes the following UFA in hci_acl_create_conn_sync where a connection still pending is command submission (conn->state == BT_OPEN) maybe freed, also since this also can happen with the likes of hci_le_create_conn_sync fix it as well: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541 CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci3 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40020", "url": "https://ubuntu.com/security/CVE-2025-40020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: fix shift-out-of-bounds issue Explicitly uses a 64-bit constant when the number of bits used for its shifting is 32 (which is the case for PC CAN FD interfaces supported by this driver). [mkl: update subject, apply manually]", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39985", "url": "https://ubuntu.com/security/CVE-2025-39985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the mcba_usb driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on these lines: \tusb_msg.dlc = cf->len; \tmemcpy(usb_msg.data, cf->data, usb_msg.dlc); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39986", "url": "https://ubuntu.com/security/CVE-2025-39986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, sun4ican_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on this line: \tdlc = cf->len; Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs a couple line below when doing: \tfor (i = 0; i < dlc; i++) \t\twritel(cf->data[i], priv->base + (dreg + i * 4)); Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39987", "url": "https://ubuntu.com/security/CVE-2025-39987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. The driver will consume frame->len as-is with no further checks. This can result in a buffer overflow later on in hi3110_hw_tx() on this line: \tmemcpy(buf + HI3110_FIFO_EXT_DATA_OFF, \t frame->data, frame->len); Here, frame->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39988", "url": "https://ubuntu.com/security/CVE-2025-39988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the etas_es58x driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)); to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, es58x_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN(FD) frame. This can result in a buffer overflow. For example, using the es581.4 variant, the frame will be dispatched to es581_4_tx_can_msg(), go through the last check at the beginning of this function: \tif (can_is_canfd_skb(skb)) \t\treturn -EMSGSIZE; and reach this line: \tmemcpy(tx_can_msg->data, cf->data, cf->len); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU or CANFD_MTU (depending on the device capabilities). By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39932", "url": "https://ubuntu.com/security/CVE-2025-39932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work) In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again. I actually just hit the case using rxe: WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10 [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ... It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39940", "url": "https://ubuntu.com/security/CVE-2025-39940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stripe: fix a possible integer overflow There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39948", "url": "https://ubuntu.com/security/CVE-2025-39948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix Rx page leak on multi-buffer frames The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver. It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed. If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf(). Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc. The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page. Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with \"jumbo frames\" used by 9K MTU. To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts(). Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() on the last buffer of the frame indicating the end of packet. For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss. The xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame. Move the increment of the ntc local variable to ensure its updated *before* all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic requires the index of the element just after the current frame. Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rx_ring.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39950", "url": "https://ubuntu.com/security/CVE-2025-39950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR A NULL pointer dereference can occur in tcp_ao_finish_connect() during a connect() system call on a socket with a TCP-AO key added and TCP_REPAIR enabled. The function is called with skb being NULL and attempts to dereference it on tcp_hdr(skb)->seq without a prior skb validation. Fix this by checking if skb is NULL before dereferencing it. The commentary is taken from bpf_skops_established(), which is also called in the same flow. Unlike the function being patched, bpf_skops_established() validates the skb before dereferencing it. int main(void){ \tstruct sockaddr_in sockaddr; \tstruct tcp_ao_add tcp_ao; \tint sk; \tint one = 1; \tmemset(&sockaddr,'\\0',sizeof(sockaddr)); \tmemset(&tcp_ao,'\\0',sizeof(tcp_ao)); \tsk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); \tsockaddr.sin_family = AF_INET; \tmemcpy(tcp_ao.alg_name,\"cmac(aes128)\",12); \tmemcpy(tcp_ao.key,\"ABCDEFGHABCDEFGH\",16); \ttcp_ao.keylen = 16; \tmemcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); \tsetsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao, \tsizeof(tcp_ao)); \tsetsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one)); \tsockaddr.sin_family = AF_INET; \tsockaddr.sin_port = htobe16(123); \tinet_aton(\"127.0.0.1\", &sockaddr.sin_addr); \tconnect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr)); return 0; } $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall $ unshare -Urn BUG: kernel NULL pointer dereference, address: 00000000000000b6 PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39961", "url": "https://ubuntu.com/security/CVE-2025-39961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd/pgtbl: Fix possible race while increase page table level The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] \t\t\t\t\t Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.", "cve_priority": "medium", "cve_public_date": "2025-10-09 13:15:00 UTC" }, { "cve": "CVE-2025-22106", "url": "https://ubuntu.com/security/CVE-2025-22106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: unregister xdp rxq info in the reset path vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace. Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0 This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39934", "url": "https://ubuntu.com/security/CVE-2025-39934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39937", "url": "https://ubuntu.com/security/CVE-2025-39937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda (\"net: rfkill: gpio: get the name and type from device property\") rfkill_find_type() gets called with the possibly uninitialized \"const char *type_name;\" local variable. On x86 systems when rfkill-gpio binds to a \"BCM4752\" or \"LNV4752\" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no \"type\" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a \"BCM4752\"/\"LNV4752\" acpi_device 2. The stack happened to contain NULL where type_name is stored", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39938", "url": "https://ubuntu.com/security/CVE-2025-39938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and \"dai_data->graph[dai->id]\" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39942", "url": "https://ubuntu.com/security/CVE-2025-39942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size This is inspired by the check for data_offset + data_length.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39943", "url": "https://ubuntu.com/security/CVE-2025-39943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: validate data_offset and data_length field of smb_direct_data_transfer If data_offset and data_length of smb_direct_data_transfer struct are invalid, out of bounds issue could happen. This patch validate data_offset and data_length field in recv_done.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39944", "url": "https://ubuntu.com/security/CVE-2025-39944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp() The original code relies on cancel_delayed_work() in otx2_ptp_destroy(), which does not ensure that the delayed work item synctstamp_work has fully completed if it was already running. This leads to use-after-free scenarios where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp(). Furthermore, the synctstamp_work is cyclic, the likelihood of triggering the bug is nonnegligible. A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAF This is confirmed by a KASAN report: BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800aa09a18 by task bash/136 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled before the otx2_ptp is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced artificial delays within the otx2_sync_tstamp() function to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39945", "url": "https://ubuntu.com/security/CVE-2025-39945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cnic: Fix use-after-free bugs in cnic_delete_task The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39955", "url": "https://ubuntu.com/security/CVE-2025-39955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect(). syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk in the TCP_ESTABLISHED state. [0] syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destination As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes it to TCP_CLOSE and makes connect() possible, which restarts timers. Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the retransmit timer triggered the warning and the intended packet was not retransmitted. Let's call reqsk_fastopen_remove() in tcp_disconnect(). [0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) ", "cve_priority": "medium", "cve_public_date": "2025-10-09 10:15:00 UTC" }, { "cve": "CVE-2025-39947", "url": "https://ubuntu.com/security/CVE-2025-39947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Harden uplink netdev access against device unbind The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39949", "url": "https://ubuntu.com/security/CVE-2025-39949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qed: Don't collect too many protection override GRC elements In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer. This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESS where \"ADDRESS\" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure. The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783 or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663 Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39951", "url": "https://ubuntu.com/security/CVE-2025-39951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: virtio_uml: Fix use-after-free after put_device in probe When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39953", "url": "https://ubuntu.com/security/CVE-2025-39953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: split cgroup_destroy_wq into 3 workqueues A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction. Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio Call Trace: \tcgroup_lock_and_drain_offline+0x14c/0x1e8 \tcgroup_destroy_root+0x3c/0x2c0 \tcss_free_rwork_fn+0x248/0x338 \tprocess_one_work+0x16c/0x3b8 \tworker_thread+0x22c/0x3b0 \tkthread+0xec/0x100 \tret_from_fork+0x10/0x20 Root Cause: CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues \t\t\t\t// cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1) Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation This separation eliminates blocking in the CSS free path while waiting for offline operations to complete. [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39957", "url": "https://ubuntu.com/security/CVE-2025-39957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: increase scan_ies_len for S1G Currently the S1G capability element is not taken into account for the scan_ies_len, which leads to a buffer length validation failure in ieee80211_prep_hw_scan() and subsequent WARN in __ieee80211_start_scan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length.", "cve_priority": "medium", "cve_public_date": "2025-10-09 10:15:00 UTC" }, { "cve": "CVE-2025-39952", "url": "https://ubuntu.com/security/CVE-2025-39952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: avoid buffer overflow in WID string configuration Fix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537) This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39927", "url": "https://ubuntu.com/security/CVE-2025-39927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix race condition validating r_parent before applying state Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39923", "url": "https://ubuntu.com/security/CVE-2025-39923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2]. Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs. [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/ [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39869", "url": "https://ubuntu.com/security/CVE-2025-39869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map Fix a critical memory allocation bug in edma_setup_from_hw() where queue_priority_map was allocated with insufficient memory. The code declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8), but allocated memory using sizeof(s8) instead of the correct size. This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i; The bug manifested as kernel crashes with \"Oops - undefined instruction\" on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the memory corruption triggered kernel hardening features on Clang. Change the allocation to use sizeof(*queue_priority_map) which automatically gets the correct size for the 2D array structure.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39873", "url": "https://ubuntu.com/security/CVE-2025-39873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB can_put_echo_skb() takes ownership of the SKB and it may be freed during or after the call. However, xilinx_can xcan_write_frame() keeps using SKB after the call. Fix that by only calling can_put_echo_skb() after the code is done touching the SKB. The tx_lock is held for the entire xcan_write_frame() execution and also on the can_get_echo_skb() side so the order of operations does not matter. An earlier fix commit 3d3c817c3a40 (\"can: xilinx_can: Fix usage of skb memory\") did not move the can_put_echo_skb() call far enough. [mkl: add \"commit\" in front of sha1 in patch description] [mkl: fix indention]", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39911", "url": "https://ubuntu.com/security/CVE-2025-39911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration later than the first, the error path wants to free the IRQs requested so far. However, it uses the wrong dev_id argument for free_irq(), so it does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]--- Use the same dev_id for free_irq() as for request_irq(). I tested this with inserting code to fail intentionally.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39876", "url": "https://ubuntu.com/security/CVE-2025-39876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() The function of_phy_find_device may return NULL, so we need to take care before dereferencing phy_dev.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39881", "url": "https://ubuntu.com/security/CVE-2025-39881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernfs: Fix UAF in polling when open file is released A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism: BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1 psi_trigger_poll+0x3c/0x140 cgroup_pressure_poll+0x70/0xa0 cgroup_file_poll+0x8c/0x100 kernfs_fop_poll+0x11c/0x1c0 ep_item_poll.isra.0+0x188/0x2c0 Allocated by task 1: cgroup_file_open+0x88/0x388 kernfs_fop_open+0x73c/0xaf0 do_dentry_open+0x5fc/0x1200 vfs_open+0xa0/0x3f0 do_open+0x7e8/0xd08 path_openat+0x2fc/0x6b0 do_filp_open+0x174/0x368 Freed by task 8462: cgroup_file_release+0x130/0x1f8 kernfs_drain_open_files+0x17c/0x440 kernfs_drain+0x2dc/0x360 kernfs_show+0x1b8/0x288 cgroup_file_show+0x150/0x268 cgroup_pressure_write+0x1dc/0x340 cgroup_file_write+0x274/0x548 Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv epolling\t\t\tdisable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epoll_wait kernfs_fop_poll kernfs_get_active = true\techo 0 > cgroup.pressure ...\t\t\t\tcgroup_file_show \t\t\t\tkernfs_show \t\t\t\t// inactive kn \t\t\t\tkernfs_drain_open_files \t\t\t\tcft->release(of); \t\t\t\tkfree(ctx); \t\t\t\t... kernfs_get_active = false \t\t\t\techo 1 > cgroup.pressure \t\t\t\tkernfs_show \t\t\t\tkernfs_activate_one(kn); kernfs_fop_poll kernfs_get_active = true cgroup_file_poll psi_trigger_poll // UAF ... end: close(fd) To address this issue, introduce kernfs_get_active_of() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfs_get_active() with kernfs_get_active_of() to prevent further operations on released file descriptors.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39909", "url": "https://ubuntu.com/security/CVE-2025-39909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters() Patch series \"mm/damon: avoid divide-by-zero in DAMON module's parameters application\". DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors. Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters. This patch (of 2): During the calculation of 'hot_thres' and 'cold_thres', either 'sample_interval' or 'aggr_interval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggr_interval' is already required to be set no smaller than 'sample_interval' in damon_set_attrs(), only the case where 'sample_interval' is zero needs to be checked.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39916", "url": "https://ubuntu.com/security/CVE-2025-39916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters() When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39877", "url": "https://ubuntu.com/security/CVE-2025-39877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: fix use-after-free in state_show() state_show() reads kdamond->damon_ctx without holding damon_sysfs_lock. This allows a use-after-free race: CPU 0 CPU 1 ----- ----- state_show() damon_sysfs_turn_damon_on() ctx = kdamond->damon_ctx; mutex_lock(&damon_sysfs_lock); damon_destroy_ctx(kdamond->damon_ctx); kdamond->damon_ctx = NULL; mutex_unlock(&damon_sysfs_lock); damon_is_running(ctx); /* ctx is freed */ mutex_lock(&ctx->kdamond_lock); /* UAF */ (The race can also occur with damon_sysfs_kdamonds_rm_dirs() and damon_sysfs_kdamond_release(), which free or replace the context under damon_sysfs_lock.) Fix by taking damon_sysfs_lock before dereferencing the context, mirroring the locking used in pid_show(). The bug has existed since state_show() first accessed kdamond->damon_ctx.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39880", "url": "https://ubuntu.com/security/CVE-2025-39880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix invalid accesses to ceph_connection_v1_info There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use). On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets. con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39883", "url": "https://ubuntu.com/security/CVE-2025-39883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory When I did memory failure tests, below panic occurs: page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 Modules linked in: hwpoison_inject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- The root cause is that unpoison_memory() tries to check the PG_HWPoison flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps: 1.Offline memory block: echo offline > /sys/devices/system/memory/memory12/state 2.Get offlined memory pfn: page-types -b n -rlN 3.Write pfn to unpoison-pfn echo > /sys/kernel/debug/hwpoison/unpoison-pfn This scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail if pfn_to_online_page() == NULL to fix the bug.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39907", "url": "https://ubuntu.com/security/CVE-2025-39907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer Avoid below overlapping mappings by using a contiguous non-cacheable buffer. [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST, overlapping mappings aren't supported [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300 [ 4.097071] Modules linked in: [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1 [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT) [ 4.118824] Workqueue: events_unbound deferred_probe_work_func [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.131624] pc : add_dma_entry+0x23c/0x300 [ 4.135658] lr : add_dma_entry+0x23c/0x300 [ 4.139792] sp : ffff800009dbb490 [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000 [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8 [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20 [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006 [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58 [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000 [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40 [ 4.214185] Call trace: [ 4.216605] add_dma_entry+0x23c/0x300 [ 4.220338] debug_dma_map_sg+0x198/0x350 [ 4.224373] __dma_map_sg_attrs+0xa0/0x110 [ 4.228411] dma_map_sg_attrs+0x10/0x2c [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174 [ 4.242127] nand_read_oob+0x1d4/0x8e0 [ 4.245861] mtd_read_oob_std+0x58/0x84 [ 4.249596] mtd_read_oob+0x90/0x150 [ 4.253231] mtd_read+0x68/0xac", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39885", "url": "https://ubuntu.com/security/CVE-2025-39885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix recursive semaphore deadlock in fiemap call syzbot detected a OCFS2 hang due to a recursive semaphore on a FS_IOC_FIEMAP of the extent list on a specially crafted mmap file. context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline] RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline] RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline] RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26 Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89 f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41 RSP: 0018:ffffc9000403f950 EFLAGS: 00050256 RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038 RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060 RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42 R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098 R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f13850fd9 RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9 RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004 RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0 R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the extent list of this running mmap executable. The user supplied buffer to hold the fiemap information page faults calling ocfs2_page_mkwrite() which will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same semaphore. This recursive semaphore will hold filesystem locks and causes a hang of the fileystem. The ip_alloc_sem protects the inode extent list and size. Release the read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap() and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock on the last extent but simplifies the error path.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39913", "url": "https://ubuntu.com/security/CVE-2025-39913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork. syzbot reported the splat below. [0] The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytes At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes(). Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN. If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc(). Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork. The \"*copied\" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets \"*copied\" to 0. [0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 ", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39886", "url": "https://ubuntu.com/security/CVE-2025-39886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init() Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example: ... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ... The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event. We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc. As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there. Depends on mm patch \"memcg: skip cgroup_file_notify if spinning is not allowed\": https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/ v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39914", "url": "https://ubuntu.com/security/CVE-2025-39914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Silence warning when chunk allocation fails in trace_pid_write Syzkaller trigger a fault injection warning: WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning. The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-23143", "url": "https://ubuntu.com/security/CVE-2025-23143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod. When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1] Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule At step 3), the CIFS module calls sock_release() for the underlying TCP socket, and it returns quickly. However, the socket remains in FIN_WAIT_1 because incoming FIN packets are dropped. At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sock_release() and it returns, the TCP socket does not die immediately in order to close the connection gracefully. While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sk_lock using sock_lock_init_class_and_name(). Once an incoming packet is processed for the socket or a timer fires, sk->sk_lock is acquired. Then, LOCKDEP checks the lock context in check_wait_context(), where hlock_class() is called to retrieve the lock class. However, since the module has already been unloaded, hlock_class() logs a warning and returns NULL, triggering the null-ptr-deref. If LOCKDEP is enabled, we must ensure that a module calling sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue. Let's hold the module reference in sock_lock_init_class_and_name() and release it when the socket is freed in sk_prot_free(). Note that sock_lock_init() clears sk->sk_owner for svc_create_socket() that calls sock_lock_init_class_and_name() for a listening socket, which clones a socket by sk_clone_lock() without GFP_ZERO. [0]: CIFS_SERVER=\"10.0.0.137\" CIFS_PATH=\"//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST\" DEV=\"enp0s3\" CRED=\"/root/WindowsCredential.txt\" MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire (kernel/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-22124", "url": "https://ubuntu.com/security/CVE-2025-22124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb In clustermd, separate write-intent-bitmaps are used for each cluster node: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal to bitmap->storage.file_pages. Then bitmap_limit will be calculated to 0. md_super_write() will be called with 0 size. That means the first 4k sb area of node 1 will never be updated through filemap_write_page(). This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize. Here use (pg_index % bitmap->storage.file_pages) to make calculation of bitmap_limit correct.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-23133", "url": "https://ubuntu.com/security/CVE-2025-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: update channel list in reg notifier instead reg worker Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list(). But ath11k will immediately execute step 3 after reg_work is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0 Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set, cfg80211 will notify ath11k after step 2 is done. So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/ Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22113", "url": "https://ubuntu.com/security/CVE-2025-22113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid journaling sb update on error if journal is destroying Presently we always BUG_ON if trying to start a transaction on a journal marked with JBD2_UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for update_super_work to start a transaction after the journal is destroyed eg: (umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super \tflush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT) Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit. Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updates This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc86606) Also, we don't need a similar check in ext4_grp_locked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22125", "url": "https://ubuntu.com/security/CVE-2025-22125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: don't ignore IO flags If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced. Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks. Fix those problems by keep IO flags from master bio. Fises: f51d46d0e7cb (\"md: add support for REQ_NOWAIT\")", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39899", "url": "https://ubuntu.com/security/CVE-2025-39899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using kmap_local_page(), which requires unmapping in Last-In-First-Out order. The current code maps dst_pte first, then src_pte, but unmaps them in the same order (dst_pte, src_pte), violating the LIFO requirement. This causes the warning in kunmap_local_indexed(): WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c addr \\!= __fix_to_virt(FIX_KMAP_BEGIN + idx) Fix this by reversing the unmap order to respect LIFO ordering. This issue follows the same pattern as similar fixes: - commit eca6828403b8 (\"crypto: skcipher - fix mismatch between mapping and unmapping order\") - commit 8cf57c6df818 (\"nilfs2: eliminate staggered calls to kunmap in nilfs_rename\") Both of which addressed the same fundamental requirement that kmap_local operations must follow LIFO ordering.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39897", "url": "https://ubuntu.com/security/CVE-2025-39897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Add error handling for RX metadata pointer retrieval Add proper error checking for dmaengine_desc_get_metadata_ptr() which can return an error pointer and lead to potential crashes or undefined behaviour if the pointer retrieval fails. Properly handle the error by unmapping DMA buffer, freeing the skb and returning early to prevent further processing with invalid data.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39850", "url": "https://ubuntu.com/security/CVE-2025-39850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects When the \"proxy\" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the \"any\" remote (0.0.0.0 / ::). The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4]. Fix by checking that the remote destination exists before dereferencing it. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3 [3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77 [4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39851", "url": "https://ubuntu.com/security/CVE-2025-39851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD when refreshing an FDB entry with a nexthop object VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39852", "url": "https://ubuntu.com/security/CVE-2025-39852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm \"softirq\", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need to be called. They make sure the newsk will end up being correctly free'd. tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit label that takes care of things. So, this patch here makes sure tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar error-handling and thus fixes the leak for TCP-AO.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39901", "url": "https://ubuntu.com/security/CVE-2025-39901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: remove read access to debugfs files The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c (\"i40e: debugfs interface\"). Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here. On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be \": \". For 'netdev_ops', this will be \": \". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism. We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc. A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input. Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once. In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39854", "url": "https://ubuntu.com/security/CVE-2025-39854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the \"low latency\" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same \"ready\" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-38556", "url": "https://ubuntu.com/security/CVE-2025-38556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Harden s32ton() against conversion to 0 bits Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38502", "url": "https://ubuntu.com/security/CVE-2025-38502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix oob access in cgroup local storage Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf); For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access. To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.", "cve_priority": "medium", "cve_public_date": "2025-08-16 10:15:00 UTC" }, { "cve": "CVE-2025-39843", "url": "https://ubuntu.com/security/CVE-2025-39843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: slub: avoid wake up kswapd in set_track_prepare set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock. Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since ___slab_alloc() has preemption disabled, we mask out __GFP_DIRECT_RECLAIM from the flags there. The oops looks something like: BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c ___slab_alloc+0xccc __kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39920", "url": "https://ubuntu.com/security/CVE-2025-39920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pcmcia: Add error handling for add_interval() in do_validate_mem() In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next. This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39902", "url": "https://ubuntu.com/security/CVE-2025-39902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slub: avoid accessing metadata when pointer is invalid in object_err() object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object. One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process. In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39838", "url": "https://ubuntu.com/security/CVE-2025-39838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: prevent NULL pointer dereference in UTF16 conversion There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash. This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer. Found by Linux Verification Center (linuxtesting.org) with SVACE", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39839", "url": "https://ubuntu.com/security/CVE-2025-39839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix OOB read/write in network-coding decode batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write. Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39841", "url": "https://ubuntu.com/security/CVE-2025-39841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix buffer free/clear order in deferred receive path Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39891", "url": "https://ubuntu.com/security/CVE-2025-39891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Initialize the chan_stats array to zero The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey(). There are two potential issues here. What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak. Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc().", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39842", "url": "https://ubuntu.com/security/CVE-2025-39842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: prevent release journal inode after journal shutdown Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode(). ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> \t jbd2_journal_release_jbd_inode(osb->journal->j_journal, Adding osb->journal checks will prevent null-ptr-deref during the above execution path.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39895", "url": "https://ubuntu.com/security/CVE-2025-39895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: Fix sched_numa_find_nth_cpu() if mask offline sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer. The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline): [ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000 [ 1.423635] Mem abort info: [ 1.423889] ESR = 0x0000000096000006 [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.424715] SET = 0, FnV = 0 [ 1.424995] EA = 0, S1PTW = 0 [ 1.425279] FSC = 0x06: level 2 translation fault [ 1.425735] Data abort info: [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000 [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000 [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP [ 1.429525] Modules linked in: [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT) [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488 [ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488 [ 1.432543] sp : ffffffc084e1b960 [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0 [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378 [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7 [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372 [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860 [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000 [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68 [ 1.439332] Call trace: [ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P) [ 1.440016] smp_call_function_any+0xc8/0xd0 [ 1.440416] armv8_pmu_init+0x58/0x27c [ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c [ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8 [ 1.441603] armv8_pmu_device_probe+0x1c/0x28 [ 1.442007] platform_probe+0x5c/0xac [ 1.442347] really_probe+0xbc/0x298 [ 1.442683] __driver_probe_device+0x78/0x12c [ 1.443087] driver_probe_device+0xdc/0x160 [ 1.443475] __driver_attach+0x94/0x19c [ 1.443833] bus_for_each_dev+0x74/0xd4 [ 1.444190] driver_attach+0x24/0x30 [ 1.444525] bus_add_driver+0xe4/0x208 [ 1.444874] driver_register+0x60/0x128 [ 1.445233] __platform_driver_register+0x24/0x30 [ 1.445662] armv8_pmu_driver_init+0x28/0x4c [ 1.446059] do_one_initcall+0x44/0x25c [ 1.446416] kernel_init_freeable+0x1dc/0x3bc [ 1.446820] kernel_init+0x20/0x1d8 [ 1.447151] ret_from_fork+0x10/0x20 [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803) [ 1.448040] ---[ end trace 0000000000000000 ]--- [ 1.448483] note: swapper/0[1] exited with preempt_count 1 [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.449741] SMP: stopping secondary CPUs [ 1.450105] Kernel Offset: disabled [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b [ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39844", "url": "https://ubuntu.com/security/CVE-2025-39844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: move page table sync declarations to linux/pgtable.h During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 (\"x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes\")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39845", "url": "https://ubuntu.com/security/CVE-2025-39845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure page tables are properly synchronized when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...]", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39846", "url": "https://ubuntu.com/security/CVE-2025-39846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region() In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39847", "url": "https://ubuntu.com/security/CVE-2025-39847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix memory leak in pad_compress_skb If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop; drop: kfree_skb(skb); When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak. Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39848", "url": "https://ubuntu.com/security/CVE-2025-39848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: properly unshare skbs in ax25_kiss_rcv() Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d (\"net: introduce per netns packet chains\"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without a major crash. But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not. Many thanks to Bernard Pidoux for his help, diagnosis and tests. We had a similar issue years ago fixed with commit 7aaed57c5c28 (\"phonet: properly unshare skbs in phonet_rcv()\").", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39849", "url": "https://ubuntu.com/security/CVE-2025-39849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39853", "url": "https://ubuntu.com/security/CVE-2025-39853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39857", "url": "https://ubuntu.com/security/CVE-2025-39857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc] ... Call Trace: smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 If the software RoCE device is used, ibdev->dma_device is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39860", "url": "https://ubuntu.com/security/CVE-2025-39860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() syzbot reported the splat below without a repro. In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that. The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit. bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release(). Two threads could see the same socket during the list iteration in bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF Depending on the timing, the other thread could show up in the \"Freed by task\" part. Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release(). [0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39861", "url": "https://ubuntu.com/security/CVE-2025-39861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: vhci: Prevent use-after-free by removing debugfs files early Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed. Previously, debugfs files such as \"force_suspend\", \"force_wakeup\", and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors. Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39894", "url": "https://ubuntu.com/security/CVE-2025-39894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39864", "url": "https://ubuntu.com/security/CVE-2025-39864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix use-after-free in cmp_bss() Following bss_free() quirk introduced in commit 776b3580178f (\"cfg80211: track hidden SSID networks properly\"), adjust cfg80211_update_known_bss() to free the last beacon frame elements only if they're not shared via the corresponding 'hidden_beacon_bss' pointer.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39865", "url": "https://ubuntu.com/security/CVE-2025-39865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: fix NULL pointer dereference in tee_shm_put tee_shm_put have NULL pointer dereference: __optee_disable_shm_cache --> \tshm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> \t\ttee_shm_put(shm);//crash Add check in tee_shm_put to fix it. panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39866", "url": "https://ubuntu.com/security/CVE-2025-39866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix use-after-free in __mark_inode_dirty() An use-after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching. CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 ...... pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mark_inode_dirty+0x124/0x418 lr : __mark_inode_dirty+0x118/0x418 sp : ffffffc08c9dbbc0 ........ Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198 Root cause is: systemd-random-seed kworker ---------------------------------------------------------------------- ___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39811", "url": "https://ubuntu.com/security/CVE-2025-39811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Clear the scratch_pt pointer on error Avoid triggering a dereference of an error pointer on cleanup in xe_vm_free_scratch() by clearing any scratch_pt error pointer. (cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8)", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39815", "url": "https://ubuntu.com/security/CVE-2025-39815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: fix stack overrun when loading vlenb The userspace load can put up to 2048 bits into an xlen bit stack buffer. We want only xlen bits, so check the size beforehand.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39836", "url": "https://ubuntu.com/security/CVE-2025-39836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efi: stmm: Fix incorrect buffer allocation method The communication buffer allocated by setup_mm_hdr() is later on passed to tee_shm_register_kernel_buf(). The latter expects those buffers to be contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause various corruptions or BUGs, specifically since commit 9aec2fb0fd5e (\"slab: allocate frozen pages\"), though it was broken before as well. Fix this by using alloc_pages_exact() instead of kmalloc().", "cve_priority": "medium", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39805", "url": "https://ubuntu.com/security/CVE-2025-39805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix unregister_netdev call order in macb_remove() When removing a macb device, the driver calls phy_exit() before unregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ... The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus. Fix this by moving unregister_netdev() ahead of phy_exit() in macb_remove().", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39829", "url": "https://ubuntu.com/security/CVE-2025-39829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: trace/fgraph: Fix the warning caused by missing unregister notifier This warning was triggered during testing on v6.16: notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written. Fixed by adding unregister_pm_notifier in the exception path.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39835", "url": "https://ubuntu.com/security/CVE-2025-39835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: do not propagate ENODATA disk errors into xattr code ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found. However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as \"attribute not found\" when in fact it's an IO (disk) error. At worst, we may oops in xfs_attr_leaf_get() when we do: \terror = xfs_attr_leaf_hasname(args, &bp); \tif (error == -ENOATTR) { \t\txfs_trans_brelse(args->trans, bp); \t\treturn error; \t} because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfs_trans_brelse will then null-deref it. As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don't let unique errors like this leak up into higher xfs functions - many like this should be remapped to EIO. However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later. (Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.)", "cve_priority": "low", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39819", "url": "https://ubuntu.com/security/CVE-2025-39819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb: Fix inconsistent refcnt update A possible inconsistent update of refcount was identified in `smb2_compound_op`. Such inconsistent update could lead to possible resource leaks. Why it is a possible bug: 1. In the comment section of the function, it clearly states that the reference to `cfile` should be dropped after calling this function. 2. Every control flow path would check and drop the reference to `cfile`, except the patched one. 3. Existing callers would not handle refcount update of `cfile` if -ENOMEM is returned. To fix the bug, an extra goto label \"out\" is added, to make sure that the cleanup logic would always be respected. As the problem is caused by the allocation failure of `vars`, the cleanup logic between label \"finished\" and \"out\" can be safely ignored. According to the definition of function `is_replayable_error`, the error code of \"-ENOMEM\" is not recoverable. Therefore, the replay logic also gets ignored.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39808", "url": "https://ubuntu.com/security/CVE-2025-39808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version() in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58) add null check logic to ntrig_report_version() before calling hid_to_usb_dev()", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39806", "url": "https://ubuntu.com/security/CVE-2025-39806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it. Below is the KASAN splat after the out of bounds access happens: [ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 [...]", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39824", "url": "https://ubuntu.com/security/CVE-2025-39824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix UAF via HID_CLAIMED_INPUT validation After hid_hw_start() is called hidinput_connect() will eventually be called to set up the device with the input layer since the HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect() all input and output reports are processed and corresponding hid_inputs are allocated and configured via hidinput_configure_usages(). This process involves slot tagging report fields and configuring usages by setting relevant bits in the capability bitmaps. However it is possible that the capability bitmaps are not set at all leading to the subsequent hidinput_has_been_populated() check to fail leading to the freeing of the hid_input and the underlying input device. This becomes problematic because a malicious HID device like a ASUS ROG N-Key keyboard can trigger the above scenario via a specially crafted descriptor which then leads to a user-after-free when the name of the freed input device is written to later on after hid_hw_start(). Below, report 93 intentionally utilises the HID_UP_UNDEFINED Usage Page which is skipped during usage configuration, leading to the frees. 0x05, 0x0D, // Usage Page (Digitizer) 0x09, 0x05, // Usage (Touch Pad) 0xA1, 0x01, // Collection (Application) 0x85, 0x0D, // Report ID (13) 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) 0x09, 0xC5, // Usage (0xC5) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x04, // Report Count (4) 0xB1, 0x02, // Feature (Data,Var,Abs) 0x85, 0x5D, // Report ID (93) 0x06, 0x00, 0x00, // Usage Page (Undefined) 0x09, 0x01, // Usage (0x01) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x1B, // Report Count (27) 0x81, 0x02, // Input (Data,Var,Abs) 0xC0, // End Collection Below is the KASAN splat after triggering the UAF: [ 21.672709] ================================================================== [ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80 [ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54 [ 21.673700] [ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary) [ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 21.673700] Call Trace: [ 21.673700] [ 21.673700] dump_stack_lvl+0x5f/0x80 [ 21.673700] print_report+0xd1/0x660 [ 21.673700] kasan_report+0xe5/0x120 [ 21.673700] __asan_report_store8_noabort+0x1b/0x30 [ 21.673700] asus_probe+0xeeb/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 [...] [ 21.673700] [ 21.673700] Allocated by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_alloc_info+0x3b/0x50 [ 21.673700] __kasan_kmalloc+0x9c/0xa0 [ 21.673700] __kmalloc_cache_noprof+0x139/0x340 [ 21.673700] input_allocate_device+0x44/0x370 [ 21.673700] hidinput_connect+0xcb6/0x2630 [ 21.673700] hid_connect+0xf74/0x1d60 [ 21.673700] hid_hw_start+0x8c/0x110 [ 21.673700] asus_probe+0x5a3/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 [...] [ 21.673700] [ 21.673700] Freed by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_free_info+0x3f/0x60 [ 21.673700] __kasan_slab_free+0x3c/0x50 [ 21.673700] kfre ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39823", "url": "https://ubuntu.com/security/CVE-2025-39823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: use array_index_nospec with indices that come from guest min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39817", "url": "https://ubuntu.com/security/CVE-2025-39817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare Observed on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0 If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename: T1\t\t\tT2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list \t\t\tlookup_open \t\t\t d_alloc_parallel \t\t\t __d_lookup_rcu \t\t\t __d_lookup_rcu_op_compare \t\t\t hlist_bl_for_each_entry_rcu \t\t\t // invalid dentry can be retrieved \t\t\t ->d_compare \t\t\t efivarfs_d_compare \t\t\t // oob Fix it by checking 'guid' before cmp.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39812", "url": "https://ubuntu.com/security/CVE-2025-39812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: initialize more fields in sctp_v6_from_sk() syzbot found that sin6_scope_id was not properly initialized, leading to undefined behavior. Clear sin6_scope_id and sin6_flowinfo. BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39827", "url": "https://ubuntu.com/security/CVE-2025-39827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: include node references in rose_neigh refcount Current implementation maintains two separate reference counting mechanisms: the 'count' field in struct rose_neigh tracks references from rose_node structures, while the 'use' field (now refcount_t) tracks references from rose_sock. This patch merges these two reference counting systems using 'use' field for proper reference management. Specifically, this patch adds incrementing and decrementing of rose_neigh->use when rose_neigh->count is incremented or decremented. This patch also modifies rose_rt_free(), rose_rt_device_down() and rose_clear_route() to properly release references to rose_neigh objects before freeing a rose_node through rose_remove_node(). These changes ensure rose_neigh structures are properly freed only when all references, including those from rose_node structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39826", "url": "https://ubuntu.com/security/CVE-2025-39826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: convert 'use' field to refcount_t The 'use' field in struct rose_neigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a rose_neigh structure is freed while still being referenced by other code paths. For example, when rose_neigh->use becomes zero during an ioctl operation via rose_rt_ioctl(), the structure may be removed while its timer is still active, potentially causing use-after-free issues. This patch changes the type of 'use' from unsigned short to refcount_t and updates all code paths to use rose_neigh_hold() and rose_neigh_put() which operate reference counts atomically.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39832", "url": "https://ubuntu.com/security/CVE-2025-39832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix lockdep assertion on sync reset unload event Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning. Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39828", "url": "https://ubuntu.com/security/CVE-2025-39828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control(). syzbot reported the splat below. [0] When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message. The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc. The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer. struct atmtcp_control { \tstruct atmtcp_hdr hdr;\t/* must be first */ ... \tatm_kptr_t vcc;\t\t/* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t; The special message is processed in atmtcp_recv_control() called from atmtcp_c_send(). atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control. Let's add a new ->pre_send() hook to validate messages from sendmsg(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 Modules linked in:", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39697", "url": "https://ubuntu.com/security/CVE-2025-39697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39825", "url": "https://ubuntu.com/security/CVE-2025-39825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix race with concurrent opens in rename(2) Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file. Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39813", "url": "https://ubuntu.com/security/CVE-2025-39813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix potential warning in trace_printk_seq during ftrace_dump When calling ftrace_dump_one() concurrently with reading trace_pipe, a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race condition. The issue occurs because: CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger !trace_empty(&iter) trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipe trace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULL trace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size) In the context between trace_empty() and trace_find_next_entry_inc() during ftrace_dump, the ring buffer data was consumed by other readers. This caused trace_find_next_entry_inc to return NULL, failing to populate `iter.seq`. At this point, due to the prior trace_iterator_reset, both `iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal, the WARN_ON_ONCE condition is triggered. Move the trace_printk_seq() into the if block that checks to make sure the return value of trace_find_next_entry_inc() is non-NULL in ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before subsequent operations.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-37899", "url": "https://ubuntu.com/security/CVE-2025-37899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in session logoff The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-22037", "url": "https://ubuntu.com/security/CVE-2025-22037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference in alloc_preauth_hash() The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauth_info is not allocated. This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2141774, 2141778, 2141411, 1786013, 2141314, 2127764, 2137613, 2138120, 2136958, 2130240, 2067642, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664 ], "changes": [ { "cves": [], "log": [ "", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux", "version": "6.8.0-106.106", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Fri, 06 Mar 2026 03:43:25 +0300" }, { "cves": [], "log": [ "", " * noble/linux: 6.8.0-104.104 -proposed tracker (LP: #2141774)", "", " * Change of ABI in 6.8.0 kernel breaks some OTT modules (LP: #2141778)", " - Revert \"net: tls: Cancel RX async resync request on rcd_delta overflow\"", " - Revert \"net: tls: Change async resync helpers argument\"", "" ], "package": "linux", "version": "6.8.0-104.104", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141774, 2141778 ], "author": "Edoardo Canepa ", "date": "Fri, 13 Feb 2026 19:36:26 +0100" }, { "cves": [ { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68198", "url": "https://ubuntu.com/security/CVE-2025-68198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crash: fix crashkernel resource shrink When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues: 1. Invalid crashkernel resource objects 2. Kernel crash if crashkernel shrinking is done twice For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as: cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel Instead, it should show 50MB: af000000-b21fffff : Crash kernel Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86): BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated. Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-38627", "url": "https://ubuntu.com/security/CVE-2025-38627", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic The decompress_io_ctx may be released asynchronously after I/O completion. If this file is deleted immediately after read, and the kworker of processing post_read_wq has not been executed yet due to high workloads, It is possible that the inode(f2fs_inode_info) is evicted and freed before it is used f2fs_free_dic. The UAF case as below: Thread A Thread B - f2fs_decompress_end_io - f2fs_put_dic - queue_work add free_dic work to post_read_wq - do_unlink - iput - evict - call_rcu This file is deleted after read. Thread C kworker to process post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inode is freed by rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem read (dic->inode)->i_compress_algorithm This patch store compress_algorithm and sbi in dic to avoid inode UAF. In addition, the previous solution is deprecated in [1] may cause system hang. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68204", "url": "https://ubuntu.com/security/CVE-2025-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: arm: scmi: Fix genpd leak on provider registration failure If of_genpd_add_provider_onecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpd_debug_add(). Add proper error handling to unwind the initialized domains before returning from probe to ensure all resources are correctly released on failure. Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-22107", "url": "https://ubuntu.com/security/CVE-2025-22107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39981", "url": "https://ubuntu.com/security/CVE-2025-39981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible UAFs This attemps to fix possible UAFs caused by struct mgmt_pending being freed while still being processed like in the following trace, in order to fix mgmt_pending_valid is introduce and use to check if the mgmt_pending hasn't been removed from the pending list, on the complete callbacks it is used to check and in addtion remove the cmd from the list while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd is left on the list it can still be accessed and freed. BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55 CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245 Allocated by task 12210: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 sock_write_iter+0x258/0x330 net/socket.c:1133 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 12221: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4648 [inline] kfree+0x18e/0x440 mm/slub.c:4847 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline] hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526 sock_do_ioctl+0xd9/0x300 net/socket.c:1192 sock_ioctl+0x576/0x790 net/socket.c:1313 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-22121", "url": "https://ubuntu.com/security/CVE-2025-22121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-23129", "url": "https://ubuntu.com/security/CVE-2025-23129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath11k_pci_alloc_msi(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This results in the below warning: WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c Call trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc The warning is due to not clearing the affinity hint before freeing the IRQs. So to fix this issue, clear the IRQ affinity hint before calling ath11k_pcic_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-40287", "url": "https://ubuntu.com/security/CVE-2025-40287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix improper check of dentry.stream.valid_size We found an infinite loop bug in the exFAT file system that can lead to a Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is malformed, the following system calls — SYS_openat, SYS_ftruncate, and SYS_pwrite64 — can cause the kernel to hang. Root cause analysis shows that the size validation code in exfat_find() does not check whether dentry.stream.valid_size is negative. As a result, the system calls mentioned above can succeed and eventually trigger the DoS issue. This patch adds a check for negative dentry.stream.valid_size to prevent this vulnerability.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40289", "url": "https://ubuntu.com/security/CVE-2025-40289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM Otherwise accessing them can cause a crash.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68201", "url": "https://ubuntu.com/security/CVE-2025-68201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: remove two invalid BUG_ON()s Those can be triggered trivially by userspace.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68180", "url": "https://ubuntu.com/security/CVE-2025-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref in debugfs odm_combine_segments When a connector is connected but inactive (e.g., disabled by desktop environments), pipe_ctx->stream_res.tg will be destroyed. Then, reading odm_combine_segments causes kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Fix this by checking pipe_ctx-> ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68322", "url": "https://ubuntu.com/security/CVE-2025-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parisc: Avoid crash due to unaligned access in unwinder Guenter Roeck reported this kernel crash on his emulated B160L machine: Starting network: udhcpc: started, v1.36.1 Backtrace: [<104320d4>] unwind_once+0x1c/0x5c [<10434a00>] walk_stackframe.isra.0+0x74/0xb8 [<10434a6c>] arch_stack_walk+0x28/0x38 [<104e5efc>] stack_trace_save+0x48/0x5c [<105d1bdc>] set_track_prepare+0x44/0x6c [<105d9c80>] ___slab_alloc+0xfc4/0x1024 [<105d9d38>] __slab_alloc.isra.0+0x58/0x90 [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0 [<105b8e54>] __anon_vma_prepare+0x60/0x280 [<105a823c>] __vmf_anon_prepare+0x68/0x94 [<105a8b34>] do_wp_page+0x8cc/0xf10 [<105aad88>] handle_mm_fault+0x6c0/0xf08 [<10425568>] do_page_fault+0x110/0x440 [<10427938>] handle_interruption+0x184/0x748 [<11178398>] schedule+0x4c/0x190 BUG: spinlock recursion on CPU#0, ifconfig/2420 lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0 While creating the stack trace, the unwinder uses the stack pointer to guess the previous frame to read the previous stack pointer from memory. The crash happens, because the unwinder tries to read from unaligned memory and as such triggers the unalignment trap handler which then leads to the spinlock recursion and finally to a deadlock. Fix it by checking the alignment before accessing the memory.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40305", "url": "https://ubuntu.com/security/CVE-2025-40305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN p9_read_work() doesn't set Rworksched and doesn't do schedule_work(m->rq) if list_empty(&m->req_list). However, if the pipe is full, we need to read more data and this used to work prior to commit aaec5a95d59615 (\"pipe_read: don't wake up the writer if the pipe is still full\"). p9_read_work() does p9_fd_read() -> ... -> anon_pipe_read() which (before the commit above) triggered the unnecessary wakeup. This wakeup calls p9_pollwake() which kicks p9_poll_workfn() -> p9_poll_mux(), p9_poll_mux() will notice EPOLLIN and schedule_work(&m->rq). This no longer happens after the optimization above, change p9_fd_request() to use p9_poll_mux() instead of only checking for EPOLLOUT.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40307", "url": "https://ubuntu.com/security/CVE-2025-40307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: validate cluster allocation bits of the allocation bitmap syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68190", "url": "https://ubuntu.com/security/CVE-2025-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked() kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68315", "url": "https://ubuntu.com/security/CVE-2025-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to detect potential corrupted nid in free_nid_list As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fs_alloc_nid() to detect any potential corruption in free_nid_list.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40339", "url": "https://ubuntu.com/security/CVE-2025-40339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix nullptr err of vm_handle_moved If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68311", "url": "https://ubuntu.com/security/CVE-2025-68311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: serial: ip22zilog: Use platform device for probing After commit 84a9582fd203 (\"serial: core: Start managing serial controllers to enable runtime PM\") serial drivers need to provide a device in struct uart_port.dev otherwise an oops happens. To fix this issue for ip22zilog driver switch driver to a platform driver and setup the serial device in sgi-ip22 code.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68313", "url": "https://ubuntu.com/security/CVE-2025-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Add RDSEED fix for Zen5 There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 \"at a rate inconsistent with randomness while incorrectly signaling success (CF=1)\". Search the web for AMD-SB-7055 for more detail. Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40360", "url": "https://ubuntu.com/security/CVE-2025-40360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Do not dereference NULL pointer in plane reset The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL. v2: - fix typo in commit description (Javier)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68734", "url": "https://ubuntu.com/security/CVE-2025-68734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe() In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when setup_instance() fails with an error code. Fix that by freeing the urb before freeing the hw structure. Also change the error paths to use the goto ladder style. Compile tested only. Issue found using a prototype static analysis tool.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-40272", "url": "https://ubuntu.com/security/CVE-2025-40272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix use-after-free race in fault handler When a page fault occurs in a secret memory file created with `memfd_secret(2)`, the kernel will allocate a new folio for it, mark the underlying page as not-present in the direct map, and add it to the file mapping. If two tasks cause a fault in the same page concurrently, both could end up allocating a folio and removing the page from the direct map, but only one would succeed in adding the folio to the file mapping. The task that failed undoes the effects of its attempt by (a) freeing the folio again and (b) putting the page back into the direct map. However, by doing these two operations in this order, the page becomes available to the allocator again before it is placed back in the direct mapping. If another task attempts to allocate the page between (a) and (b), and the kernel tries to access it via the direct map, it would result in a supervisor not-present page fault. Fix the ordering to restore the direct map before the folio is freed.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40077", "url": "https://ubuntu.com/security/CVE-2025-40077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid overflow while left shift operation Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-68245", "url": "https://ubuntu.com/security/CVE-2025-68245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: fix incorrect refcount handling causing incorrect cleanup commit efa95b01da18 (\"netpoll: fix use after free\") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks. Scenario causing lack of proper cleanup: 1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one. 2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev. 3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called 4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak. Revert commit efa95b01da18 (\"netpoll: fix use after free\") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40293", "url": "https://ubuntu.com/security/CVE-2025-40293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Don't overflow during division for dirty tracking If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow to 0 and this triggers divide by 0. In this case the index should just be 0, so reorganize things to divide by shift and avoid hitting any overflows.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40303", "url": "https://ubuntu.com/security/CVE-2025-40303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: ensure no dirty metadata is written back for an fs with errors [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68184", "url": "https://ubuntu.com/security/CVE-2025-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Disable AFBC support on Mediatek DRM driver Commit c410fa9b07c3 (\"drm/mediatek: Add AFBC support to Mediatek DRM driver\") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier. However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0. Kernel trace reports vblank timeouts constantly, and the render is garbled: ``` [CRTC:62:crtc-0] vblank wait timed out WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c [...] Hardware name: MediaTek Genio-700 EVK (DT) Workqueue: events_unbound commit_work pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c sp : ffff80008337bca0 x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000 x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70 x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ``` Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40268", "url": "https://ubuntu.com/security/CVE-2025-40268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: client: fix memory leak in smb3_fs_context_parse_param The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation. To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing. syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444 BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40269", "url": "https://ubuntu.com/security/CVE-2025-40269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential overflow of PCM transfer buffer The PCM stream data in USB-audio driver is transferred over USB URB packet buffers, and each packet size is determined dynamically. The packet sizes are limited by some factors such as wMaxPacketSize USB descriptor. OTOH, in the current code, the actually used packet sizes are determined only by the rate and the PPS, which may be bigger than the size limit above. This results in a buffer overflow, as reported by syzbot. Basically when the limit is smaller than the calculated packet size, it implies that something is wrong, most likely a weird USB descriptor. So the best option would be just to return an error at the parameter setup time before doing any further operations. This patch introduces such a sanity check, and returns -EINVAL when the packet size is greater than maxpacksize. The comparison with ep->packsize[1] alone should suffice since it's always equal or greater than ep->packsize[0].", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40271", "url": "https://ubuntu.com/security/CVE-2025-40271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc: fix uaf in proc_readdir_de() Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \\ NULL pde(tun2)", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68241", "url": "https://ubuntu.com/security/CVE-2025-68241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random. The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked. CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak] This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = N Ido Schimmel provided the simple test validation method [1]. The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed. [1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \\ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \\ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \\ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-68246", "url": "https://ubuntu.com/security/CVE-2025-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: close accepted socket when per-IP limit rejects connection When the per-IP connection limit is exceeded in ksmbd_kthread_fn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS. Release client_sk before continuing. This bug was found with ZeroPath.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40273", "url": "https://ubuntu.com/security/CVE-2025-40273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: free copynotify stateid in nfs4_free_ol_stateid() Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period. However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd] This patch, instead, frees the associated copynotify stateid here. If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later. [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68208", "url": "https://ubuntu.com/security/CVE-2025-68208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: account for current allocated stack depth in widen_imprecise_scalars() The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st); Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loop Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68200", "url": "https://ubuntu.com/security/CVE-2025-68200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add bpf_prog_run_data_pointers() syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 (\"net/sched: Extend qdisc control block with tc control block\"), which added a wrong interaction with db58ba459202 (\"bpf: wire in data and data_end for cls_act_bpf\"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40275", "url": "https://ubuntu.com/security/CVE-2025-40275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd In snd_usb_create_streams(), for UAC version 3 devices, the Interface Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this call fails, a fallback routine attempts to obtain the IAD from the next interface and sets a BADD profile. However, snd_usb_mixer_controls_badd() assumes that the IAD retrieved from usb_ifnum_to_if() is always valid, without performing a NULL check. This can lead to a NULL pointer dereference when usb_ifnum_to_if() fails to find the interface descriptor. This patch adds a NULL pointer check after calling usb_ifnum_to_if() in snd_usb_mixer_controls_badd() to prevent the dereference. This issue was discovered by syzkaller, which triggered the bug by sending a crafted USB device descriptor.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40277", "url": "https://ubuntu.com/security/CVE-2025-40277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40278", "url": "https://ubuntu.com/security/CVE-2025-40278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak Fix a KMSAN kernel-infoleak detected by the syzbot . [net?] KMSAN: kernel-infoleak in __skb_datagram_iter In tcf_ife_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied. This change silences the KMSAN report and prevents potential information leaks from the kernel memory. This fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures no infoleak.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40279", "url": "https://ubuntu.com/security/CVE-2025-40279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: act_connmark: initialize struct tc_ife to fix kernel leak In tcf_connmark_dump(), the variable 'opt' was partially initialized using a designatied initializer. While the padding bytes are reamined uninitialized. nla_put() copies the entire structure into a netlink message, these uninitialized bytes leaked to userspace. Initialize the structure with memset before assigning its fields to ensure all members and padding are cleared prior to beign copied.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40280", "url": "https://ubuntu.com/security/CVE-2025-40280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_mon_reinit_self(). syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0] The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL. tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work(). Let's hold RTNL in tipc_net_finalize_work(). [0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989 CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40281", "url": "https://ubuntu.com/security/CVE-2025-40281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto syzbot reported a possible shift-out-of-bounds [1] Blamed commit added rto_alpha_max and rto_beta_max set to 1000. It is unclear if some sctp users are setting very large rto_alpha and/or rto_beta. In order to prevent user regression, perform the test at run time. Also add READ_ONCE() annotations as sysctl values can change under us. [1] UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41 shift exponent 64 is too large for 32-bit type 'unsigned int' CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40282", "url": "https://ubuntu.com/security/CVE-2025-40282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: 6lowpan: reset link-local header on ipv6 recv path Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW Add missing skb_reset_mac_header() for uncompressed ipv6 RX path. For the compressed one, it is done in lowpan_header_decompress(). Log: (BlueZ 6lowpan-tester Client Recv Raw - Success) ------ kernel BUG at net/core/skbuff.c:212! Call Trace: ... packet_rcv (net/packet/af_packet.c:2152) ... __local_bh_enable_ip (kernel/softirq.c:407) netif_rx (net/core/dev.c:5648) chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359) ------", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40283", "url": "https://ubuntu.com/security/CVE-2025-40283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF There is a KASAN: slab-use-after-free read in btusb_disconnect(). Calling \"usb_driver_release_interface(&btusb_driver, data->intf)\" will free the btusb data associated with the interface. The same data is then used later in the function, hence the UAF. Fix by moving the accesses to btusb data to before the data is free'd.", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40284", "url": "https://ubuntu.com/security/CVE-2025-40284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: cancel mesh send timer when hdev removed mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone. Cancel the timer when MGMT removes the hdev, like other MGMT timers. Should fix the BUG: sporadically seen by BlueZ test bot (in \"Mesh - Send cancel - 1\" test). Log: ------ BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40285", "url": "https://ubuntu.com/security/CVE-2025-40285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix possible refcount leak in smb2_sess_setup() Reference count of ksmbd_session will leak when session need reconnect. Fix this by adding the missing ksmbd_user_session_put().", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40286", "url": "https://ubuntu.com/security/CVE-2025-40286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: fix possible memory leak in smb2_read() Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree().", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-40288", "url": "https://ubuntu.com/security/CVE-2025-40288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices Previously, APU platforms (and other scenarios with uninitialized VRAM managers) triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL, but that `man->bdev` (the backing device pointer within the manager) remains uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to acquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to a kernel OOPS. 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference. 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL. 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report). This approach is more robust than APU-specific checks because it: - Works for all scenarios where the VRAM manager is uninitialized (not just APUs), - Aligns with TTM's design by using its native helper function, - Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check). v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)", "cve_priority": "medium", "cve_public_date": "2025-12-06 22:15:00 UTC" }, { "cve": "CVE-2025-68244", "url": "https://ubuntu.com/security/CVE-2025-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD On completion of i915_vma_pin_ww(), a synchronous variant of dma_fence_work_commit() is called. When pinning a VMA to GGTT address space on a Cherry View family processor, or on a Broxton generation SoC with VTD enabled, i.e., when stop_machine() is then called from intel_ggtt_bind_vma(), that can potentially lead to lock inversion among reservation_ww and cpu_hotplug locks. [86.861179] ====================================================== [86.861193] WARNING: possible circular locking dependency detected [86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U [86.861226] ------------------------------------------------------ [86.861238] i915_module_loa/1432 is trying to acquire lock: [86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50 [86.861290] but task is already holding lock: [86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915] [86.862233] which lock already depends on the new lock. [86.862251] the existing dependency chain (in reverse order) is: [86.862265] -> #5 (reservation_ww_class_mutex){+.+.}-{3:3}: [86.862292] dma_resv_lockdep+0x19a/0x390 [86.862315] do_one_initcall+0x60/0x3f0 [86.862334] kernel_init_freeable+0x3cd/0x680 [86.862353] kernel_init+0x1b/0x200 [86.862369] ret_from_fork+0x47/0x70 [86.862383] ret_from_fork_asm+0x1a/0x30 [86.862399] -> #4 (reservation_ww_class_acquire){+.+.}-{0:0}: [86.862425] dma_resv_lockdep+0x178/0x390 [86.862440] do_one_initcall+0x60/0x3f0 [86.862454] kernel_init_freeable+0x3cd/0x680 [86.862470] kernel_init+0x1b/0x200 [86.862482] ret_from_fork+0x47/0x70 [86.862495] ret_from_fork_asm+0x1a/0x30 [86.862509] -> #3 (&mm->mmap_lock){++++}-{3:3}: [86.862531] down_read_killable+0x46/0x1e0 [86.862546] lock_mm_and_find_vma+0xa2/0x280 [86.862561] do_user_addr_fault+0x266/0x8e0 [86.862578] exc_page_fault+0x8a/0x2f0 [86.862593] asm_exc_page_fault+0x27/0x30 [86.862607] filldir64+0xeb/0x180 [86.862620] kernfs_fop_readdir+0x118/0x480 [86.862635] iterate_dir+0xcf/0x2b0 [86.862648] __x64_sys_getdents64+0x84/0x140 [86.862661] x64_sys_call+0x1058/0x2660 [86.862675] do_syscall_64+0x91/0xe90 [86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e [86.862703] -> #2 (&root->kernfs_rwsem){++++}-{3:3}: [86.862725] down_write+0x3e/0xf0 [86.862738] kernfs_add_one+0x30/0x3c0 [86.862751] kernfs_create_dir_ns+0x53/0xb0 [86.862765] internal_create_group+0x134/0x4c0 [86.862779] sysfs_create_group+0x13/0x20 [86.862792] topology_add_dev+0x1d/0x30 [86.862806] cpuhp_invoke_callback+0x4b5/0x850 [86.862822] cpuhp_issue_call+0xbf/0x1f0 [86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320 [86.862852] __cpuhp_setup_state+0xb0/0x220 [86.862866] topology_sysfs_init+0x30/0x50 [86.862879] do_one_initcall+0x60/0x3f0 [86.862893] kernel_init_freeable+0x3cd/0x680 [86.862908] kernel_init+0x1b/0x200 [86.862921] ret_from_fork+0x47/0x70 [86.862934] ret_from_fork_asm+0x1a/0x30 [86.862947] -> #1 (cpuhp_state_mutex){+.+.}-{3:3}: [86.862969] __mutex_lock+0xaa/0xed0 [86.862982] mutex_lock_nested+0x1b/0x30 [86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320 [86.863012] __cpuhp_setup_state+0xb0/0x220 [86.863026] page_alloc_init_cpuhp+0x2d/0x60 [86.863041] mm_core_init+0x22/0x2d0 [86.863054] start_kernel+0x576/0xbd0 [86.863068] x86_64_start_reservations+0x18/0x30 [86.863084] x86_64_start_kernel+0xbf/0x110 [86.863098] common_startup_64+0x13e/0x141 [86.863114] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [86.863135] __lock_acquire+0x16 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40292", "url": "https://ubuntu.com/security/CVE-2025-40292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix received length check in big packets Since commit 4959aebba8c0 (\"virtio-net: use mtu size as buffer length for big packets\"), when guest gso is off, the allocated size for big packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on negotiated MTU. The number of allocated frags for big packets is stored in vi->big_packets_num_skbfrags. Because the host announced buffer length can be malicious (e.g. the host vhost_net driver's get_rx_bufs is modified to announce incorrect length), we need a check in virtio_net receive path. Currently, the check is not adapted to the new change which can lead to NULL page pointer dereference in the below while loop when receiving length that is larger than the allocated one. This commit fixes the received length check corresponding to the new change.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40328", "url": "https://ubuntu.com/security/CVE-2025-40328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_close_cached_fid() find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free. Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40294", "url": "https://ubuntu.com/security/CVE-2025-40294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern() In the parse_adv_monitor_pattern() function, the value of the 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251). The size of the 'value' array in the mgmt_adv_pattern structure is 31. If the value of 'pattern[i].length' is set in the user space and exceeds 31, the 'patterns[i].value' array can be accessed out of bound when copied. Increasing the size of the 'value' array in the 'mgmt_adv_pattern' structure will break the userspace. Considering this, and to avoid OOB access revert the limits for 'offset' and 'length' back to the value of HCI_MAX_AD_LENGTH. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40329", "url": "https://ubuntu.com/security/CVE-2025-40329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()). CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0. Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock This will deadlock if f1 and f2 share the same spinlock. To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work(). [phasta: commit message nits]", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68320", "url": "https://ubuntu.com/security/CVE-2025-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix sleeping in atomic context The following warning was seen when we try to connect using ssh to the device. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear preempt_count: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE Tainted: [W]=WARN Hardware name: Generic DT based system Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x7c/0xac dump_stack_lvl from __might_resched+0x16c/0x2b0 __might_resched from __mutex_lock+0x64/0xd34 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from lan966x_stats_get+0x5c/0x558 lan966x_stats_get from dev_get_stats+0x40/0x43c dev_get_stats from dev_seq_printf_stats+0x3c/0x184 dev_seq_printf_stats from dev_seq_show+0x10/0x30 dev_seq_show from seq_read_iter+0x350/0x4ec seq_read_iter from seq_read+0xfc/0x194 seq_read from proc_reg_read+0xac/0x100 proc_reg_read from vfs_read+0xb0/0x2b0 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8 It seems that we are using a mutex in a atomic context which is wrong. Change the mutex with a spinlock.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68192", "url": "https://ubuntu.com/security/CVE-2025-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks. Initialize the MAC header to prevent such crashes. This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface. Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40331", "url": "https://ubuntu.com/security/CVE-2025-40331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: Prevent TOCTOU out-of-bounds write For the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump() make sure not to exceed bounds in case the address list has grown between buffer allocation (time-of-check) and write (time-of-use).", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40301", "url": "https://ubuntu.com/security/CVE-2025-40301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: validate skb length for unknown CC opcode In hci_cmd_complete_evt(), if the command complete event has an unknown opcode, we assume the first byte of the remaining skb->data contains the return status. However, parameter data has previously been pulled in hci_event_func(), which may leave the skb empty. If so, using skb->data[0] for the return status uses un-init memory. The fix is to check skb->len before using skb->data.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40358", "url": "https://ubuntu.com/security/CVE-2025-40358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: stacktrace: Disable KASAN checks for non-current tasks Unwinding the stack of a task other than current, KASAN would report \"BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460\" There is a same issue on x86 and has been resolved by the commit 84936118bdf3 (\"x86/unwind: Disable KASAN checks for non-current tasks\") The solution could be applied to RISC-V too. This patch also can solve the issue: https://seclists.org/oss-sec/2025/q4/23 [pjw@kernel.org: clean up checkpatch issues]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40304", "url": "https://ubuntu.com/security/CVE-2025-40304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches. Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68183", "url": "https://ubuntu.com/security/CVE-2025-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file. For example, on Fedora, after booting the kernel with \"ima_appraise=fix evm=fix ima_policy=appraise_tcb\" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404... This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed. Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL. Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset. Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = \"/usr/sbin/test_binary\"; const char* hex_string = \"030204d33204490066306402304\"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror(\"Error opening file\"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, \"%2hhx\", &ima_attr_value[j]); } if (fsetxattr(fd, \"security.ima\", ima_attr_value, length/2, 0) == -1) { perror(\"Error setting extended attribute\"); close(fd); return 1; } const char* selinux_value= \"system_u:object_r:bin_t:s0\"; if (fsetxattr(fd, \"security.selinux\", selinux_value, strlen(selinux_value), 0) == -1) { perror(\"Error setting extended attribute\"); close(fd); return 1; } close(fd); return 0; }", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68173", "url": "https://ubuntu.com/security/CVE-2025-68173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix softlockup in ftrace_module_enable A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc (\"ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels\") and commit 42ea22e754ba (\"ftrace: Add cond_resched() to ftrace_graph_set_hash()\"). Fix it the same way by adding cond_resched() in ftrace_module_enable.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40306", "url": "https://ubuntu.com/security/CVE-2025-40306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau forwarded me a message from Disclosure with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr \"security.capability\" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for \"security.capability\" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40308", "url": "https://ubuntu.com/security/CVE-2025-40308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bcsp: receive data only if registered Currently, bcsp_recv() can be called even when the BCSP protocol has not been registered. This leads to a NULL pointer dereference, as shown in the following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f To prevent this, ensure that the HCI_UART_REGISTERED flag is set before processing received data. If the protocol is not registered, return -EUNATCH.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40309", "url": "https://ubuntu.com/security/CVE-2025-40309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on sco_conn_free BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline] BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline] BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352 CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci13 hci_cmd_sync_work Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40310", "url": "https://ubuntu.com/security/CVE-2025-40310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw There is race in amdgpu_amdkfd_device_fini_sw and interrupt. if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated. kernel panic log: BUG: kernel NULL pointer dereference, address: 0000000000000098 amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP PGD d78c68067 P4D d78c68067 kfd kfd: amdgpu: Allocated 3969056 bytes on gart PUD 1465b8067 PMD @ Oops: @002 [#1] SMP NOPTI kfd kfd: amdgpu: Total number of KFD nodes to be created: 4 CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40 Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc 89 c6 e8 07 38 5d RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018 0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098 ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020 0000000000000000 R11: 0000000000000000 R12: 0900000000000002 ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00 CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033 CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400 PKRU: 55555554 Call Trace: kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu] ? amdgpu_fence_process+0xa4/0x150 [amdgpu] kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace amdgpu_irq_dispatch+0x165/0x210 [amdgpu] amdgpu_ih_process+0x80/0x100 [amdgpu] amdgpu: Virtual CRAT table created for GPU amdgpu_irq_handler+0x1f/@x60 [amdgpu] __handle_irq_event_percpu+0x3d/0x170 amdgpu: Topology: Add dGPU node [0x74a2:0x1002] handle_irq_event+0x5a/@xcO handle_edge_irq+0x93/0x240 kfd kfd: amdgpu: KFD node 1 partition @ size 49148M asm_call_irq_on_stack+0xf/@x20 common_interrupt+0xb3/0x130 asm_common_interrupt+0x1le/0x40 5.10.134-010.a1i5000.a18.x86_64 #1", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40311", "url": "https://ubuntu.com/security/CVE-2025-40311", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: support mapping cb with vmalloc-backed coherent memory When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction. Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68185", "url": "https://ubuntu.com/security/CVE-2025-68185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68176", "url": "https://ubuntu.com/security/CVE-2025-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: cadence: Check for the existence of cdns_pcie::ops before using it cdns_pcie::ops might not be populated by all the Cadence glue drivers. This is going to be true for the upcoming Sophgo platform which doesn't set the ops. Hence, add a check to prevent NULL pointer dereference. [mani: reworded subject and description]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68168", "url": "https://ubuntu.com/security/CVE-2025-68168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix uninitialized waitqueue in transaction manager The transaction manager initialization in txInit() was not properly initializing TxBlock[0].waitor waitqueue, causing a crash when txEnd(0) is called on read-only filesystems. When a filesystem is mounted read-only, txBegin() returns tid=0 to indicate no transaction. However, txEnd(0) still gets called and tries to access TxBlock[0].waitor via tid_to_tblock(0), but this waitqueue was never initialized because the initialization loop started at index 1 instead of 0. This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEnd Fix by ensuring all transaction blocks including TxBlock[0] have their waitqueues properly initialized during txInit().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40312", "url": "https://ubuntu.com/security/CVE-2025-40312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Verify inode mode when loading from disk The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 (\"isofs: Verify inode mode when loading from disk\") does.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40333", "url": "https://ubuntu.com/security/CVE-2025-40333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix infinite loop in __insert_extent_tree() When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68321", "url": "https://ubuntu.com/security/CVE-2025-68321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: page_pool: always add GFP_NOWARN for ATOMIC allocations Driver authors often forget to add GFP_NOWARN for page allocation from the datapath. This is annoying to users as OOMs are a fact of life, and we pretty much expect network Rx to hit page allocation failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations by default.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68191", "url": "https://ubuntu.com/security/CVE-2025-68191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udp_tunnel: use netdev_warn() instead of netdev_WARN() netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug. udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug. Replace netdev_WARN() with netdev_warn() accordingly.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40313", "url": "https://ubuntu.com/security/CVE-2025-40313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: pretend $Extend records as regular files Since commit af153bb63a33 (\"vfs: catch invalid modes in may_open()\") requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/ S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40314", "url": "https://ubuntu.com/security/CVE-2025-40314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free. Fix: By separating the usb_del_gadget_udc() operation into distinct \"del\" and \"put\" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget(). A patch similar to bb9c74a5bd14(\"usb: dwc3: gadget: Free gadget structure only after freeing endpoints\").", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40337", "url": "https://ubuntu.com/security/CVE-2025-40337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Correctly handle Rx checksum offload errors The stmmac_rx function would previously set skb->ip_summed to CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype. However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause corrupt packets to be passed up the network stack as valid. This patch corrects the logic by checking the `csum_none` status flag, which is set when the hardware reports a checksum error. If this flag is set, skb->ip_summed is now correctly set to CHECKSUM_NONE, ensuring the kernel's network stack will perform its own validation and properly handle the corrupt packet.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68194", "url": "https://ubuntu.com/security/CVE-2025-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: imon: make send_packet() more robust syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1]. First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls). Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away. but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed. Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb). Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf (\"[media] imon: don't wedge hardware after early callbacks\"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a (\"[media] imon: don't parse scancodes until intf configured\") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task). Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40363", "url": "https://ubuntu.com/security/CVE-2025-40363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv6: fix field-spanning memcpy warning in AH output Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field \"&top_iph->saddr\" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439 The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68178", "url": "https://ubuntu.com/security/CVE-2025-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix possible deadlock while configuring policy Following deadlock can be triggered easily by lockdep: WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted ------------------------------------------------------ check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180 but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30 -> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock); Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context. The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40341", "url": "https://ubuntu.com/security/CVE-2025-40341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Don't leak robust_list pointer on exec race sys_get_robust_list() and compat_get_robust_list() use ptrace_may_access() to check if the calling task is allowed to access another task's robust_list pointer. This check is racy against a concurrent exec() in the target process. During exec(), a task may transition from a non-privileged binary to a privileged one (e.g., setuid binary) and its credentials/memory mappings may change. If get_robust_list() performs ptrace_may_access() before this transition, it may erroneously allow access to sensitive information after the target becomes privileged. A racy access allows an attacker to exploit a window during which ptrace_may_access() passes before a target process transitions to a privileged state via exec(). For example, consider a non-privileged task T that is about to execute a setuid-root binary. An attacker task A calls get_robust_list(T) while T is still unprivileged. Since ptrace_may_access() checks permissions based on current credentials, it succeeds. However, if T begins exec immediately afterwards, it becomes privileged and may change its memory mappings. Because get_robust_list() proceeds to access T->robust_list without synchronizing with exec() it may read user-space pointers from a now-privileged process. This violates the intended post-exec access restrictions and could expose sensitive memory addresses or be used as a primitive in a larger exploit chain. Consequently, the race can lead to unauthorized disclosure of information across privilege boundaries and poses a potential security risk. Take a read lock on signal->exec_update_lock prior to invoking ptrace_may_access() and accessing the robust_list/compat_robust_list. This ensures that the target task's exec state remains stable during the check, allowing for consistent and synchronized validation of credentials.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40342", "url": "https://ubuntu.com/security/CVE-2025-40342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: use lock accessing port_state and rport state nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-40343", "url": "https://ubuntu.com/security/CVE-2025-40343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid scheduling association deletion twice When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted.", "cve_priority": "medium", "cve_public_date": "2025-12-09 16:17:00 UTC" }, { "cve": "CVE-2025-68177", "url": "https://ubuntu.com/security/CVE-2025-68177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq/longhaul: handle NULL policy in longhaul_exit longhaul_exit() was calling cpufreq_cpu_get(0) without checking for a NULL policy pointer. On some systems, this could lead to a NULL dereference and a kernel warning or panic. This patch adds a check using unlikely() and returns early if the policy is NULL. Bugzilla: #219962", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40315", "url": "https://ubuntu.com/security/CVE-2025-40315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix epfile null pointer access after ep enable. A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable(). The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock. Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68310", "url": "https://ubuntu.com/security/CVE-2025-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do. During error recovery testing a pair of tasks was reported to be hung: mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core] No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too: - task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock() - task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock. A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/ reporter fw_fatal while PCI error recovery is executed on the same physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with \"kernel answers: Permission denied\" - and we get a kernel log message of: mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5 because the config read of VSC_SEMAPHORE is rejected by the underlying hardware. Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68179", "url": "https://ubuntu.com/security/CVE-2025-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible crashes. The problem is that kernel page tables are modified without flushing corresponding TLB entries. Even if it looks like the empty flush_tlb_all() implementation on s390 is the problem, it is actually a different problem: on s390 it is not allowed to replace an active/valid page table entry with another valid page table entry without the detour over an invalid entry. A direct replacement may lead to random crashes and/or data corruption. In order to invalidate an entry special instructions have to be used (e.g. ipte or idte). Alternatively there are also special instructions available which allow to replace a valid entry with a different valid entry (e.g. crdte or cspg). Given that the HVO code currently does not provide the hooks to allow for an implementation which is compliant with the s390 architecture requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is basically a revert of the original patch which enabled it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40317", "url": "https://ubuntu.com/security/CVE-2025-40317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: slimbus: fix bus_context pointer in regmap init calls Commit 4e65bda8273c (\"ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()\") revealed the problem in the slimbus regmap. That commit breaks audio playback, for instance, on sdm845 Thundercomm Dragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19c The __devm_regmap_init_slimbus() started to be used instead of __regmap_init_slimbus() after the commit mentioned above and turns out the incorrect bus_context pointer (3rd argument) was used in __devm_regmap_init_slimbus(). It should be just \"slimbus\" (which is equal to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or the first user of devm_regmap_init_slimbus() but we should fix it till the point where __devm_regmap_init_slimbus() was introduced therefore two \"Fixes\" tags. While at this, also correct the same argument in __regmap_init_slimbus().", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40318", "url": "https://ubuntu.com/security/CVE-2025-40318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once hci_cmd_sync_dequeue_once() does lookup and then cancel the entry under two separate lock sections. Meanwhile, hci_cmd_sync_work() can also delete the same entry, leading to double list_del() and \"UAF\". Fix this by holding cmd_sync_work_lock across both lookup and cancel, so that the entry cannot be removed concurrently.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68312", "url": "https://ubuntu.com/security/CVE-2025-68312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: Prevents free active kevent The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the \"free active object (kevent)\" error reported here. 2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed. The solution to this problem is to cancel the kevent before executing free_netdev().", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68172", "url": "https://ubuntu.com/security/CVE-2025-68172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aspeed - fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the manual clock cleanup in both aspeed_acry_probe()'s error path and aspeed_acry_remove().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40319", "url": "https://ubuntu.com/security/CVE-2025-40319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Sync pending IRQ work before freeing ring buffer Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work complete before freeing the buffer.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68171", "url": "https://ubuntu.com/security/CVE-2025-68171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Ensure XFD state on signal delivery Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40320", "url": "https://ubuntu.com/security/CVE-2025-40320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential cfid UAF in smb2_query_info_compound When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free. Reinitialize cfid to NULL under the replay label. Example trace (trimmed): refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40321", "url": "https://ubuntu.com/security/CVE-2025-40321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode Currently, whenever there is a need to transmit an Action frame, the brcmfmac driver always uses the P2P vif to send the \"actframe\" IOVAR to firmware. The P2P interfaces were available when wpa_supplicant is managing the wlan interface. However, the P2P interfaces are not created/initialized when only hostapd is managing the wlan interface. And if hostapd receives an ANQP Query REQ Action frame even from an un-associated STA, the brcmfmac driver tries to use an uninitialized P2P vif pointer for sending the IOVAR to firmware. This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000) Fix this, by always using the vif corresponding to the wdev on which the Action frame Transmission request was initiated by the userspace. This way, even if P2P vif is not available, the IOVAR is sent to firmware on AP vif and the ANQP Query RESP Action frame is transmitted without crashing the driver. Move init_completion() for \"send_af_done\" from brcmf_p2p_create_p2pdev() to brcmf_p2p_attach(). Because the former function would not get executed when only hostapd is managing wlan interface, and it is not safe to do reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior init_completion(). And in the brcmf_p2p_tx_action_frame() function, the condition check for P2P Presence response frame is not needed, since the wpa_supplicant is properly sending the P2P Presense Response frame on the P2P-GO vif instead of the P2P-Device vif. [Cc stable]", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40322", "url": "https://ubuntu.com/security/CVE-2025-40322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: bitblit: bound-check glyph index in bit_putcs* bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address. This fixes a global out-of-bounds read reported by syzbot.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40211", "url": "https://ubuntu.com/security/CVE-2025-40211", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: video: Fix use-after-free in acpi_video_switch_brightness() The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal. If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight. Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed. [ rjw: Changelog edit ]", "cve_priority": "medium", "cve_public_date": "2025-11-21 11:15:00 UTC" }, { "cve": "CVE-2025-40323", "url": "https://ubuntu.com/security/CVE-2025-40323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Set fb_display[i]->mode to NULL when the mode is released Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-40324", "url": "https://ubuntu.com/security/CVE-2025-40324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix crash in nfsd4_read_release() When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-37860", "url": "https://ubuntu.com/security/CVE-2025-37860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: fix NULL dereferences in ef100_process_design_param() Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point. Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err.", "cve_priority": "medium", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21833", "url": "https://ubuntu.com/security/CVE-2025-21833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE There is a WARN_ON_ONCE to catch an unlikely situation when domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless happens we must avoid using a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2025-03-06 17:15:00 UTC" }, { "cve": "CVE-2025-22105", "url": "https://ubuntu.com/security/CVE-2025-22105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: check xdp prog when set bond mode Following operations can trigger a warning[1]: ip netns add ns1 ip netns exec ns1 ip link add bond0 type bond mode balance-rr ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp ip netns exec ns1 ip link set bond0 type bond mode broadcast ip netns del ns1 When delete the namespace, dev_xdp_uninstall() is called to remove xdp program on bond dev, and bond_xdp_set() will check the bond mode. If bond mode is changed after attaching xdp program, the warning may occur. Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode with xdp program attached is not good. Add check for xdp program when set bond mode. [1] ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930 Modules linked in: CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930 Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ... RSP: 0018:ffffc90000063d80 EFLAGS: 00000282 RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48 RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8 R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000 FS: 0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0 Call Trace: ? __warn+0x83/0x130 ? unregister_netdevice_many_notify+0x8d9/0x930 ? report_bug+0x18e/0x1a0 ? handle_bug+0x54/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? unregister_netdevice_many_notify+0x8d9/0x930 ? bond_net_exit_batch_rtnl+0x5c/0x90 cleanup_net+0x237/0x3d0 process_one_work+0x163/0x390 worker_thread+0x293/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0xec/0x1e0 ? __pfx_kthread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-38643", "url": "https://ubuntu.com/security/CVE-2025-38643", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac() Callers of wdev_chandef() must hold the wiphy mutex. But the worker cfg80211_propagate_cac_done_wk() never takes the lock. Which triggers the warning below with the mesh_peer_connected_dfs test from hostapd and not (yet) released mac80211 code changes: WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211_propagate_cac_done_wk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985", "cve_priority": "medium", "cve_public_date": "2025-08-22 16:15:00 UTC" }, { "cve": "CVE-2025-23130", "url": "https://ubuntu.com/security/CVE-2025-23130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid panic once fallocation fails for pinfile syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation. In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg()", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-40353", "url": "https://ubuntu.com/security/CVE-2025-40353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: mte: Do not warn if the page is already tagged in copy_highpage() The arm64 copy_highpage() assumes that the destination page is newly allocated and not MTE-tagged (PG_mte_tagged unset) and warns accordingly. However, following commit 060913999d7a (\"mm: migrate: support poisoned recover from migrate folio\"), folio_mc_copy() is called before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the copy will be done again to the same destination page. Since copy_highpage() already set the PG_mte_tagged flag, this second copy will warn. Replace the WARN_ON_ONCE(page already tagged) in the arm64 copy_highpage() with a comment.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-39678", "url": "https://ubuntu.com/security/CVE-2025-39678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL If metric table address is not allocated, accessing metrics_bin will result in a NULL pointer dereference, so add a check.", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-40235", "url": "https://ubuntu.com/security/CVE-2025-40235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots() If fs_info->super_copy or fs_info->super_for_commit allocated failed in btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info(). Otherwise btrfs_check_leaked_roots() would access NULL pointer because fs_info->allocated_roots had not been initialised. syzkaller reported the following information: ------------[ cut here ]------------ BUG: unable to handle page fault for address: fffffffffffffbb0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...) RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline] RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline] RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline] RIP: 0010:refcount_read include/linux/refcount.h:170 [inline] RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230 [...] Call Trace: btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280 btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029 btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097 vfs_get_tree+0x98/0x320 fs/super.c:1759 do_new_mount+0x357/0x660 fs/namespace.c:3899 path_mount+0x716/0x19c0 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount fs/namespace.c:4427 [inline] __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f032eaffa8d [...]", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40238", "url": "https://ubuntu.com/security/CVE-2025-40238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix IPsec cleanup over MPV device When we do mlx5e_detach_netdev() we eventually disable blocking events notifier, among those events are IPsec MPV events from IB to core. So before disabling those blocking events, make sure to also unregister the devcom device and mark all this device operations as complete, in order to prevent the other device from using invalid netdev during future devcom events which could cause the trace below. BUG: kernel NULL pointer dereference, address: 0000000000000010 PGD 146427067 P4D 146427067 PUD 146488067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 1 UID: 0 PID: 7735 Comm: devlink Tainted: GW 6.12.0-rc6_for_upstream_min_debug_2024_11_08_00_46 #1 Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] Code: 00 01 48 83 05 23 32 1e 00 01 41 b8 ed ff ff ff e9 60 ff ff ff 48 83 05 00 32 1e 00 01 eb e3 66 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 47 10 48 83 05 5f 32 1e 00 01 48 8b 50 40 48 85 d2 74 05 40 RSP: 0018:ffff88811a5c35f8 EFLAGS: 00010206 RAX: ffff888106e8ab80 RBX: ffff888107d7e200 RCX: ffff88810d6f0a00 RDX: ffff88810d6f0a00 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88811a17e620 R08: 0000000000000040 R09: 0000000000000000 R10: ffff88811a5c3618 R11: 0000000de85d51bd R12: ffff88811a17e600 R13: ffff88810d6f0a00 R14: 0000000000000000 R15: ffff8881034bda80 FS: 00007f27bdf89180(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 000000010f159005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] mlx5e_devcom_event_mpv+0x42/0x60 [mlx5_core] mlx5_devcom_send_event+0x8c/0x170 [mlx5_core] blocking_event+0x17b/0x230 [mlx5_core] notifier_call_chain+0x35/0xa0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_mp_event_replay+0x12/0x20 [mlx5_core] mlx5_ib_bind_slave_port+0x228/0x2c0 [mlx5_ib] mlx5_ib_stage_init_init+0x664/0x9d0 [mlx5_ib] ? idr_alloc_cyclic+0x50/0xb0 ? __kmalloc_cache_noprof+0x167/0x340 ? __kmalloc_noprof+0x1a7/0x430 __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe9/0x310 [mlx5_ib] ? kernfs_add_one+0x107/0x150 ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] auxiliary_bus_probe+0x3e/0x90 really_probe+0xc5/0x3a0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x62d/0x830 __auxiliary_device_add+0x3b/0xa0 ? auxiliary_device_init+0x41/0x90 add_adev+0xd1/0x150 [mlx5_core] mlx5_rescan_drivers_locked+0x21c/0x300 [mlx5_core] esw_mode_change+0x6c/0xc0 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x21e/0x640 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xe0 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x180/0x2b0 ? devlink_get_from_attrs_lock+0x170/0x170 ? devlink_nl_eswitch_get_doit+0x290/0x290 ? devlink_nl_pre_doit_port_optional+0x50/0x50 ? genl_family_rcv_msg_dumpit+0xf0/0xf0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1fc/0x2d0 netlink_sendmsg+0x1e4/0x410 __sock_sendmsg+0x38/0x60 ? sockfd_lookup_light+0x12/0x60 __sys_sendto+0x105/0x160 ? __sys_recvmsg+0x4e/0x90 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f27bc91b13a Code: bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 8b 05 fa 96 2c 00 45 89 c9 4c 63 d1 48 63 ff 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40242", "url": "https://ubuntu.com/security/CVE-2025-40242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix unlikely race in gdlm_put_lock In gdlm_put_lock(), there is a small window of time in which the DFL_UNMOUNT flag has been set but the lockspace hasn't been released, yet. In that window, dlm may still call gdlm_ast() and gdlm_bast(). To prevent it from dereferencing freed glock objects, only free the glock if the lockspace has actually been released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40083", "url": "https://ubuntu.com/security/CVE-2025-40083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: Fix null-deref in agg_dequeue To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c. To avoid code duplication, the following changes are made: 1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function. 2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it. 3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40084", "url": "https://ubuntu.com/security/CVE-2025-40084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: transport_ipc: validate payload size before reading handle handle_response() dereferences the payload as a 4-byte handle without verifying that the declared payload size is at least 4 bytes. A malformed or truncated message from ksmbd.mountd can lead to a 4-byte read past the declared payload size. Validate the size before dereferencing. This is a minimal fix to guard the initial handle read.", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40220", "url": "https://ubuntu.com/security/CVE-2025-40220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: \"By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40237", "url": "https://ubuntu.com/security/CVE-2025-40237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/notify: call exportfs_encode_fid with s_umount Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr. This issue was found by syzkaller. Race Condition Diagram: Thread 1 Thread 2 -------- -------- generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb) Which then leads to: [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none) [ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240 IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path. Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock. This form of fix was suggested by Amir in [1]. [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68249", "url": "https://ubuntu.com/security/CVE-2025-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: hdm_probe: Fix calling put_device() before device initialization The early error path in hdm_probe() can jump to err_free_mdev before &mdev->dev has been initialized with device_initialize(). Calling put_device(&mdev->dev) there triggers a device core WARN and ends up invoking kref_put(&kobj->kref, kobject_release) on an uninitialized kobject. In this path the private struct was only kmalloc'ed and the intended release is effectively kfree(mdev) anyway, so free it directly instead of calling put_device() on an uninitialized device. This removes the WARNING and fixes the pre-initialization error path.", "cve_priority": "medium", "cve_public_date": "2025-12-16 15:15:00 UTC" }, { "cve": "CVE-2025-40223", "url": "https://ubuntu.com/security/CVE-2025-40223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: Fix use-after-free in hdm_disconnect hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing. The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts). Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface(). This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40106", "url": "https://ubuntu.com/security/CVE-2025-40106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: fix divide-by-zero in comedi_buf_munge() The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands.", "cve_priority": "medium", "cve_public_date": "2025-10-31 10:15:00 UTC" }, { "cve": "CVE-2025-40226", "url": "https://ubuntu.com/security/CVE-2025-40226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Account for failed debug initialization When the SCMI debug subsystem fails to initialize, the related debug root will be missing, and the underlying descriptor will be NULL. Handle this fault condition in the SCMI debug helpers that maintain metrics counters.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40231", "url": "https://ubuntu.com/security/CVE-2025-40231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: fix lock inversion in vsock_assign_transport() Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called. The issue was introduced by commit 687aa0c5581b (\"vsock: Fix transport_* TOCTOU\") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created. Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40233", "url": "https://ubuntu.com/security/CVE-2025-40233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: clear extent cache after moving/defragmenting extents The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters(). The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range(). This ensures subsequent operations read fresh extent data from disk.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40346", "url": "https://ubuntu.com/security/CVE-2025-40346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arch_topology: Fix incorrect error check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: \"The error code within @ptr if it is an error pointer; 0 otherwise.\" This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40240", "url": "https://ubuntu.com/security/CVE-2025-40240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid NULL dereference when chunk data buffer is missing chunk->skb pointer is dereferenced in the if-block where it's supposed to be NULL only. chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list instead and do it just before replacing chunk->skb. We're sure that otherwise chunk->skb is non-NULL because of outer if() condition.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40350", "url": "https://ubuntu.com/security/CVE-2025-40350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run. Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it. To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40347", "url": "https://ubuntu.com/security/CVE-2025-40347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: fix the deadlock of enetc_mdio_lock After applying the workaround for err050089, the LS1028A platform experiences RCU stalls on RT kernel. This issue is caused by the recursive acquisition of the read lock enetc_mdio_lock. Here list some of the call stacks identified under the enetc_poll path that may lead to a deadlock: enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdio After enetc_poll acquires the read lock, a higher-priority writer attempts to acquire the lock, causing preemption. The writer detects that a read lock is already held and is scheduled out. However, readers under enetc_poll cannot acquire the read lock again because a writer is already waiting, leading to a thread hang. Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent recursive lock acquisition.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40243", "url": "https://ubuntu.com/security/CVE-2025-40243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits() The syzbot reported issue in hfs_find_set_zero_bits(): ===================================================== BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45 hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151 hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408 hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353 __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151 block_write_begin fs/buffer.c:2262 [inline] cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 cont_expand_zero fs/buffer.c:2528 [inline] cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591 hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52 hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494 hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654 notify_change+0x1993/0x1aa0 fs/attr.c:552 do_truncate+0x28f/0x310 fs/open.c:68 do_ftruncate+0x698/0x730 fs/open.c:195 do_sys_ftruncate fs/open.c:210 [inline] __do_sys_ftruncate fs/open.c:215 [inline] __se_sys_ftruncate fs/open.c:213 [inline] __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213 x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354 kmalloc_noprof include/linux/slab.h:905 [inline] hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175 hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337 get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681 get_tree_bdev+0x38/0x50 fs/super.c:1704 hfs_get_tree+0x35/0x40 fs/hfs/super.c:388 vfs_get_tree+0xb0/0x5c0 fs/super.c:1804 do_new_mount+0x738/0x1610 fs/namespace.c:3902 path_mount+0x6db/0x1e90 fs/namespace.c:4226 do_mount fs/namespace.c:4239 [inline] __do_sys_mount fs/namespace.c:4450 [inline] __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427 x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 ===================================================== The HFS_SB(sb)->bitmap buffer is allocated in hfs_mdb_get(): HFS_SB(sb)->bitmap = kmalloc(8192, GFP_KERNEL); Finally, it can trigger the reported issue because kmalloc() doesn't clear the allocated memory. If allocated memory contains only zeros, then everything will work pretty fine. But if the allocated memory contains the \"garbage\", then it can affect the bitmap operations and it triggers the reported issue. This patch simply exchanges the kmalloc() on kzalloc() with the goal to guarantee the correctness of bitmap operations. Because, newly created allocation bitmap should have all available blocks free. Potentially, initialization bitmap's read operation could not fill the whole allocated memory and \"garbage\" in the not initialized memory will be the reason of volume coruptions and file system driver bugs.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40351", "url": "https://ubuntu.com/security/CVE-2025-40351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat() The syzbot reported issue in hfsplus_delete_cat(): [ 70.682285][ T9333] ===================================================== [ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220 [ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220 [ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0 [ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310 [ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810 [ 70.685447][ T9333] do_rmdir+0x964/0xea0 [ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0 [ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0 [ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.687646][ T9333] [ 70.687856][ T9333] Uninit was stored to memory at: [ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600 [ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70 [ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0 [ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30 [ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0 [ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0 [ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.692773][ T9333] [ 70.692990][ T9333] Uninit was stored to memory at: [ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0 [ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800 [ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700 [ 70.694911][ T9333] mount_bdev+0x37b/0x530 [ 70.695320][ T9333] hfsplus_mount+0x4d/0x60 [ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.696588][ T9333] do_new_mount+0x73e/0x1630 [ 70.697013][ T9333] path_mount+0x6e3/0x1eb0 [ 70.697425][ T9333] __se_sys_mount+0x733/0x830 [ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.699730][ T9333] [ 70.699946][ T9333] Uninit was created at: [ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60 [ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0 [ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0 [ 70.701774][ T9333] allocate_slab+0x30e/0x1390 [ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0 [ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20 [ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0 [ 70.703598][ T9333] alloc_inode+0x82/0x490 [ 70.703984][ T9333] iget_locked+0x22e/0x1320 [ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0 [ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0 [ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700 [ 70.705776][ T9333] mount_bdev+0x37b/0x530 [ 70.706171][ T9333] hfsplus_mount+0x4d/0x60 [ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0 [ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0 [ 70.707444][ T9333] do_new_mount+0x73e/0x1630 [ 70.707865][ T9333] path_mount+0x6e3/0x1eb0 [ 70.708270][ T9333] __se_sys_mount+0x733/0x830 [ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150 [ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0 [ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0 [ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.710611][ T9333] [ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17 [ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.712490][ T9333] ===================================================== [ 70.713085][ T9333] Disabling lock debugging due to kernel taint [ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ... [ 70.714159][ T9333] ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40349", "url": "https://ubuntu.com/security/CVE-2025-40349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs: validate record offset in hfsplus_bmap_alloc hfsplus_bmap_alloc can trigger a crash if a record offset or length is larger than node_size [ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0 [ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183 [ 15.265949] [ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary) [ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 15.266167] Call Trace: [ 15.266168] [ 15.266169] dump_stack_lvl+0x53/0x70 [ 15.266173] print_report+0xd0/0x660 [ 15.266181] kasan_report+0xce/0x100 [ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0 [ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0 [ 15.266217] hfsplus_brec_insert+0x870/0xb00 [ 15.266222] __hfsplus_ext_write_extent+0x428/0x570 [ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910 [ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200 [ 15.266233] hfsplus_file_extend+0x5a7/0x1000 [ 15.266237] hfsplus_get_block+0x12b/0x8c0 [ 15.266238] __block_write_begin_int+0x36b/0x12c0 [ 15.266251] block_write_begin+0x77/0x110 [ 15.266252] cont_write_begin+0x428/0x720 [ 15.266259] hfsplus_write_begin+0x51/0x100 [ 15.266262] cont_write_begin+0x272/0x720 [ 15.266270] hfsplus_write_begin+0x51/0x100 [ 15.266274] generic_perform_write+0x321/0x750 [ 15.266285] generic_file_write_iter+0xc3/0x310 [ 15.266289] __kernel_write_iter+0x2fd/0x800 [ 15.266296] dump_user_range+0x2ea/0x910 [ 15.266301] elf_core_dump+0x2a94/0x2ed0 [ 15.266320] vfs_coredump+0x1d85/0x45e0 [ 15.266349] get_signal+0x12e3/0x1990 [ 15.266357] arch_do_signal_or_restart+0x89/0x580 [ 15.266362] irqentry_exit_to_user_mode+0xab/0x110 [ 15.266364] asm_exc_page_fault+0x26/0x30 [ 15.266366] RIP: 0033:0x41bd35 [ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f [ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283 [ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000 [ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100 [ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000 [ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000 [ 15.266376] When calling hfsplus_bmap_alloc to allocate a free node, this function first retrieves the bitmap from header node and map node using node->page together with the offset and length from hfs_brec_lenoff ``` len = hfs_brec_lenoff(node, 2, &off16); off = off16; off += node->page_offset; pagep = node->page + (off >> PAGE_SHIFT); data = kmap_local_page(*pagep); ``` However, if the retrieved offset or length is invalid(i.e. exceeds node_size), the code may end up accessing pages outside the allocated range for this node. This patch adds proper validation of both offset and length before use, preventing out-of-bounds page access. Move is_bnode_offset_valid and check_and_correct_requested_length to hfsplus_fs.h, as they may be required by other functions.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40244", "url": "https://ubuntu.com/security/CVE-2025-40244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() The syzbot reported issue in __hfsplus_ext_cache_extent(): [ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0 [ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.196959][ T9350] cont_write_begin+0x1000/0x1950 [ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.199393][ T9350] vfs_write+0xb0f/0x14e0 [ 70.199771][ T9350] ksys_write+0x23e/0x490 [ 70.200149][ T9350] __x64_sys_write+0x97/0xf0 [ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.202054][ T9350] [ 70.202279][ T9350] Uninit was created at: [ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80 [ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0 [ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0 [ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0 [ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0 [ 70.205074][ T9350] cont_write_begin+0x1000/0x1950 [ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130 [ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060 [ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460 [ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0 [ 70.207552][ T9350] vfs_write+0xb0f/0x14e0 [ 70.207961][ T9350] ksys_write+0x23e/0x490 [ 70.208375][ T9350] __x64_sys_write+0x97/0xf0 [ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0 [ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0 [ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 70.210230][ T9350] [ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5 [ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.212115][ T9350] ===================================================== [ 70.212734][ T9350] Disabling lock debugging due to kernel taint [ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ... [ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5 [ 70.214679][ T9350] Tainted: [B]=BAD_PAGE [ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.215999][ T9350] Call Trace: [ 70.216309][ T9350] [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0 [ 70.217025][ T9350] dump_stack+0x1e/0x30 [ 70.217421][ T9350] panic+0x502/0xca0 [ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 [ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ... kernel :[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0 set ... [ 70.221254][ T9350] ? __msan_warning+0x96/0x120 [ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990 [ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0 [ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0 [ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0 [ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950 [ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130 [ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060 [ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460 [ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0 [ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0 [ 70.228997][ T9350] ? ksys_write+0x23e/0x490 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40245", "url": "https://ubuntu.com/security/CVE-2025-40245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nios2: ensure that memblock.current_limit is set when setting pfn limits On nios2, with CONFIG_FLATMEM set, the kernel relies on memblock_get_current_limit() to determine the limits of mem_map, in particular for max_low_pfn. Unfortunately, memblock.current_limit is only default initialized to MEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading to situations where max_low_pfn can erroneously exceed the value of max_pfn and, thus, the valid range of available DRAM. This can in turn cause kernel-level paging failures, e.g.: [ 76.900000] Unable to handle kernel paging request at virtual address 20303000 [ 76.900000] ea = c0080890, ra = c000462c, cause = 14 [ 76.900000] Kernel panic - not syncing: Oops [ 76.900000] ---[ end Kernel panic - not syncing: Oops ]--- This patch fixes this by pre-calculating memblock.current_limit based on the upper limits of the available memory ranges via adjust_lowmem_bounds, a simplified version of the equivalent implementation within the arm architecture.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40105", "url": "https://ubuntu.com/security/CVE-2025-40105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: Don't leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb (\"VFS: don't keep disconnected dentries on d_anon\") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are \"leaked\". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous \"Busy inodes after unmount\" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40092", "url": "https://ubuntu.com/security/CVE-2025-40092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Refactor bind path to use __free() After an bind/unbind cycle, the ncm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40101", "url": "https://ubuntu.com/security/CVE-2025-40101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST At the end of btrfs_load_block_group_zone_info() the first thing we do is to ensure that if the mapping type is not a SINGLE one and there is no RAID stripe tree, then we return early with an error. Doing that, though, prevents the code from running the last calls from this function which are about freeing memory allocated during its run. Hence, in this case, instead of returning early, we set the ret value and fall through the rest of the cleanup code.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40166", "url": "https://ubuntu.com/security/CVE-2025-40166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Check GuC running state before deregistering exec queue In normal operation, a registered exec queue is disabled and deregistered through the GuC, and freed only after the GuC confirms completion. However, if the driver is forced to unbind while the exec queue is still running, the user may call exec_destroy() after the GuC has already been stopped and CT communication disabled. In this case, the driver cannot receive a response from the GuC, preventing proper cleanup of exec queue resources. Fix this by directly releasing the resources when GuC is not running. Here is the failure dmesg log: \" [ 468.089581] ---[ end trace 0000000000000000 ]--- [ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535) [ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535 [ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1 [ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1) [ 468.092716] ------------[ cut here ]------------ [ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe] \" v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled(). As CT may go down and come back during VF migration. (cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40104", "url": "https://ubuntu.com/security/CVE-2025-40104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ixgbevf: fix mailbox API compatibility by negotiating supported features There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API. This convention has been broken since introducing API 1.4. Commit 0062e7cc955e (\"ixgbevf: add VF IPsec offload code\") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself. Commit 339f28964147 (\"ixgbevf: Add support for new mailbox communication between PF and VF\") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes. The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 (\"ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5\"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX. To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox. New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op. Features negotiation mechanism gives possibility to be extended with new features when needed in the future.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40087", "url": "https://ubuntu.com/security/CVE-2025-40087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Define a proc_layoutcommit for the FlexFiles layout type Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40196", "url": "https://ubuntu.com/security/CVE-2025-40196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to \"events_unbound\" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance \"writeback\" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40088", "url": "https://ubuntu.com/security/CVE-2025-40088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp() The hfsplus_strcasecmp() logic can trigger the issue: [ 117.317703][ T9855] ================================================================== [ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490 [ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855 [ 117.319577][ T9855] [ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full) [ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 117.319783][ T9855] Call Trace: [ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0 [ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10 [ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0 [ 117.319816][ T9855] ? lock_release+0x4b/0x3e0 [ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40 [ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319842][ T9855] print_report+0x17e/0x7e0 [ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0 [ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0 [ 117.319862][ T9855] ? __phys_addr+0xd3/0x180 [ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319876][ T9855] kasan_report+0x147/0x180 [ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490 [ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490 [ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10 [ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0 [ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470 [ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10 [ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10 [ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510 [ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10 [ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10 [ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510 [ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0 [ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120 [ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890 [ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10 [ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0 [ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80 [ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10 [ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100 [ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150 [ 117.320034][ T9855] __lookup_slow+0x297/0x3d0 [ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10 [ 117.320045][ T9855] ? down_read+0x1ad/0x2e0 [ 117.320055][ T9855] lookup_slow+0x53/0x70 [ 117.320065][ T9855] walk_component+0x2f0/0x430 [ 117.320073][ T9855] path_lookupat+0x169/0x440 [ 117.320081][ T9855] filename_lookup+0x212/0x590 [ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10 [ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290 [ 117.320105][ T9855] ? getname_flags+0x1e5/0x540 [ 117.320112][ T9855] user_path_at+0x3a/0x60 [ 117.320117][ T9855] __x64_sys_umount+0xee/0x160 [ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10 [ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0 [ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0 [ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0 [ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07 [ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08 [ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40085", "url": "https://ubuntu.com/security/CVE-2025-40085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card In try_to_register_card(), the return value of usb_ifnum_to_if() is passed directly to usb_interface_claimed() without a NULL check, which will lead to a NULL pointer dereference when creating an invalid USB audio device. Fix this by adding a check to ensure the interface pointer is valid before passing it to usb_interface_claimed().", "cve_priority": "medium", "cve_public_date": "2025-10-29 14:15:00 UTC" }, { "cve": "CVE-2025-40172", "url": "https://ubuntu.com/security/CVE-2025-40172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() Currently, if find_and_map_user_pages() takes a DMA xfer request from the user with a length field set to 0, or in a rare case, the host receives QAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size is equal to the requested transaction size, the function will return 0 before allocating an sgt or setting the fields of the dma_xfer struct. In that case, encode_addr_size_pairs() will try to access the sgt which will lead to a general protection fault. Return an EINVAL in case the user provides a zero-sized ALP, or the device requests continuation after all of the bytes have been transferred.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40176", "url": "https://ubuntu.com/security/CVE-2025-40176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: wait for pending async decryptions if tls_strp_msg_hold fails Async decryption calls tls_strp_msg_hold to create a clone of the input skb to hold references to the memory it uses. If we fail to allocate that clone, proceeding with async decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, wait for all pending decryption requests.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40173", "url": "https://ubuntu.com/security/CVE-2025-40173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ip6_tunnel: Prevent perpetual tunnel growth Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd (\"net: ip_tunnel: prevent perpetual headroom growth\"), ipv6 tunnel yet increases the headroom without any ceiling. Reflect ipv4 tunnel headroom adjustment limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-specific patch and a reproducer.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40095", "url": "https://ubuntu.com/security/CVE-2025-40095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_rndis: Refactor bind path to use __free() After an bind/unbind cycle, the rndis->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40094", "url": "https://ubuntu.com/security/CVE-2025-40094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_acm: Refactor bind path to use __free() After an bind/unbind cycle, the acm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Call trace: usb_ep_free_request+0x2c/0xec gs_free_req+0x30/0x44 acm_bind+0x1b8/0x1f4 usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40093", "url": "https://ubuntu.com/security/CVE-2025-40093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ecm: Refactor bind path to use __free() After an bind/unbind cycle, the ecm->notify_req is left stale. If a subsequent bind fails, the unified error label attempts to free this stale request, leading to a NULL pointer dereference when accessing ep->ops->free_request. Refactor the error handling in the bind path to use the __free() automatic cleanup mechanism.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40165", "url": "https://ubuntu.com/security/CVE-2025-40165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: m2m: Fix streaming cleanup on release If streamon/streamoff calls are imbalanced, such as when exiting an application with Ctrl+C when streaming, the m2m usage_count will never reach zero and the ISI channel won't be freed. Besides from that, if the input line width is more than 2K, it will trigger a WARN_ON(): [ 59.222120] ------------[ cut here ]------------ [ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654 [ 59.238569] Modules linked in: ap1302 [ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT [ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT) [ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120 [ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120 [ 59.275047] sp : ffff8000848c3b40 [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00 [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001 [ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780 [ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000 [ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c [ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30 [ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420 [ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000 [ 59.349590] Call trace: [ 59.352025] mxc_isi_channel_chain+0xa4/0x120 (P) [ 59.356722] mxc_isi_m2m_streamon+0x160/0x20c [ 59.361072] v4l_streamon+0x24/0x30 [ 59.364556] __video_do_ioctl+0x40c/0x4a0 [ 59.368560] video_usercopy+0x2bc/0x690 [ 59.372382] video_ioctl2+0x18/0x24 [ 59.375857] v4l2_ioctl+0x40/0x60 [ 59.379168] __arm64_sys_ioctl+0xac/0x104 [ 59.383172] invoke_syscall+0x48/0x104 [ 59.386916] el0_svc_common.constprop.0+0xc0/0xe0 [ 59.391613] do_el0_svc+0x1c/0x28 [ 59.394915] el0_svc+0x34/0xf4 [ 59.397966] el0t_64_sync_handler+0xa0/0xe4 [ 59.402143] el0t_64_sync+0x198/0x19c [ 59.405801] ---[ end trace 0000000000000000 ]--- Address this issue by moving the streaming preparation and cleanup to the vb2 .prepare_streaming() and .unprepare_streaming() operations. This also simplifies the driver by allowing direct usage of the v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40096", "url": "https://ubuntu.com/security/CVE-2025-40096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies When adding dependencies with drm_sched_job_add_dependency(), that function consumes the fence reference both on success and failure, so in the latter case the dma_fence_put() on the error path (xarray failed to expand) is a double free. Interestingly this bug appears to have been present ever since commit ebd5f74255b9 (\"drm/sched: Add dependency tracking\"), since the code back then looked like this: drm_sched_job_add_implicit_dependencies(): ... for (i = 0; i < fence_count; i++) { ret = drm_sched_job_add_dependency(job, fences[i]); if (ret) break; } for (; i < fence_count; i++) dma_fence_put(fences[i]); Which means for the failing 'i' the dma_fence_put was already a double free. Possibly there were no users at that time, or the test cases were insufficient to hit it. The bug was then only noticed and fixed after commit 9c2ba265352a (\"drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2\") landed, with its fixup of commit 4eaf02d6076c (\"drm/scheduler: fix drm_sched_job_add_implicit_dependencies\"). At that point it was a slightly different flavour of a double free, which commit 963d0b356935 (\"drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder\") noticed and attempted to fix. But it only moved the double free from happening inside the drm_sched_job_add_dependency(), when releasing the reference not yet obtained, to the caller, when releasing the reference already released by the former in the failure case. As such it is not easy to identify the right target for the fixes tag so lets keep it simple and just continue the chain. While fixing we also improve the comment and explain the reason for taking the reference and not dropping it.", "cve_priority": "low", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40099", "url": "https://ubuntu.com/security/CVE-2025-40099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: parse_dfs_referrals: prevent oob on malformed input Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS - reply smaller than sizeof(struct get_dfs_referral_rsp) - reply with number of referrals smaller than NumberOfReferrals in the header Processing of such replies will cause oob. Return -EINVAL error on such replies to prevent oob-s.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40100", "url": "https://ubuntu.com/security/CVE-2025-40100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40167", "url": "https://ubuntu.com/security/CVE-2025-40167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: detect invalid INLINE_DATA + EXTENTS flag combination syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity file on a corrupted ext4 filesystem mounted without a journal. The issue is that the filesystem has an inode with both the INLINE_DATA and EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66 Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1 This is an invalid combination since an inode should have either: - INLINE_DATA: data stored directly in the inode - EXTENTS: data stored in extent-mapped blocks Having both flags causes ext4_has_inline_data() to return true, skipping extent tree validation in __ext4_iget(). The unvalidated out-of-order extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer underflow when calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40103", "url": "https://ubuntu.com/security/CVE-2025-40103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2025-40198", "url": "https://ubuntu.com/security/CVE-2025-40198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40159", "url": "https://ubuntu.com/security/CVE-2025-40159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: Harden userspace-supplied xdp_desc validation Turned out certain clearly invalid values passed in xdp_desc from userspace can pass xp_{,un}aligned_validate_desc() and then lead to UBs or just invalid frames to be queued for xmit. desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len can cause positive integer overflow and wraparound, the same way low enough desc->addr with a non-zero pool->tx_metadata_len can cause negative integer overflow. Both scenarios can then pass the validation successfully. This doesn't happen with valid XSk applications, but can be used to perform attacks. Always promote desc->len to ``u64`` first to exclude positive overflows of it. Use explicit check_{add,sub}_overflow() when validating desc->addr (which is ``u64`` already). bloat-o-meter reports a little growth of the code size: add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44) Function old new delta xskq_cons_peek_desc 299 330 +31 xsk_tx_peek_release_desc_batch 973 1002 +29 xsk_generic_xmit 3148 3132 -16 but hopefully this doesn't hurt the performance much.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40221", "url": "https://ubuntu.com/security/CVE-2025-40221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: mg4b: fix uninitialized iio scan data Fix potential leak of uninitialized stack data to userspace by ensuring that the `scan` structure is zeroed before use.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40180", "url": "https://ubuntu.com/security/CVE-2025-40180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40178", "url": "https://ubuntu.com/security/CVE-2025-40178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pid: Add a judgment for ns null in pid_nr_ns __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: \tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058 \tMem abort info: \tESR = 0x0000000096000007 \tEC = 0x25: DABT (current EL), IL = 32 bits \tSET = 0, FnV = 0 \tEA = 0, S1PTW = 0 \tFSC = 0x07: level 3 translation fault \tData abort info: \tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 \tCM = 0, WnR = 0, TnD = 0, TagAccess = 0 \tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 \t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 \tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) \tpc : __task_pid_nr_ns+0x74/0xd0 \tlr : __task_pid_nr_ns+0x24/0xd0 \tsp : ffffffc08001bd10 \tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 \tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 \tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 \tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 \tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc \tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 \tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 \tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 \tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc \tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 \tCall trace: \t__task_pid_nr_ns+0x74/0xd0 \t... \t__handle_irq_event_percpu+0xd4/0x284 \thandle_irq_event+0x48/0xb0 \thandle_fasteoi_irq+0x160/0x2d8 \tgeneric_handle_domain_irq+0x44/0x60 \tgic_handle_irq+0x4c/0x114 \tcall_on_irq_stack+0x3c/0x74 \tdo_interrupt_handler+0x4c/0x84 \tel1_interrupt+0x34/0x58 \tel1h_64_irq_handler+0x18/0x24 \tel1h_64_irq+0x68/0x6c \taccount_kernel_stack+0x60/0x144 \texit_task_stack_account+0x1c/0x80 \tdo_exit+0x7e4/0xaf8 \t... \tget_signal+0x7bc/0x8d8 \tdo_notify_resume+0x128/0x828 \tel0_svc+0x6c/0x70 \tel0t_64_sync_handler+0x68/0xbc \tel0t_64_sync+0x1a8/0x1ac \tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) \t---[ end trace 0000000000000000 ]--- \tKernel panic - not syncing: Oops: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40202", "url": "https://ubuntu.com/security/CVE-2025-40202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: Rework user message limit handling The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free. Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine. It's a lot cleaner and safer.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40032", "url": "https://ubuntu.com/security/CVE-2025-40032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 [mani: trimmed the stack trace]", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40038", "url": "https://ubuntu.com/security/CVE-2025-40038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled. BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b Note, this is essentially a reapply of commit 5c30e8101e8d (\"KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid\"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons).", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40042", "url": "https://ubuntu.com/security/CVE-2025-40042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race condition in kprobe initialization causing NULL pointer dereference There is a critical race condition in kprobe initialization that can lead to NULL pointer dereference and kernel crash. [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000 ... [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO) [1135630.269239] pc : kprobe_perf_func+0x30/0x260 [1135630.277643] lr : kprobe_dispatcher+0x44/0x60 [1135630.286041] sp : ffffaeff4977fa40 [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400 [1135630.302837] x27: 0000000000000000 x26: 0000000000000000 [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528 [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50 [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50 [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000 [1135630.349985] x17: 0000000000000000 x16: 0000000000000000 [1135630.359285] x15: 0000000000000000 x14: 0000000000000000 [1135630.368445] x13: 0000000000000000 x12: 0000000000000000 [1135630.377473] x11: 0000000000000000 x10: 0000000000000000 [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000 [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000 [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000 [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006 [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000 [1135630.429410] Call trace: [1135630.434828] kprobe_perf_func+0x30/0x260 [1135630.441661] kprobe_dispatcher+0x44/0x60 [1135630.448396] aggr_pre_handler+0x70/0xc8 [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0 [1135630.462435] brk_handler+0xbc/0xd8 [1135630.468437] do_debug_exception+0x84/0x138 [1135630.475074] el1_dbg+0x18/0x8c [1135630.480582] security_file_permission+0x0/0xd0 [1135630.487426] vfs_write+0x70/0x1c0 [1135630.493059] ksys_write+0x5c/0xc8 [1135630.498638] __arm64_sys_write+0x24/0x30 [1135630.504821] el0_svc_common+0x78/0x130 [1135630.510838] el0_svc_handler+0x38/0x78 [1135630.516834] el0_svc+0x8/0x1b0 kernel/trace/trace_kprobe.c: 1308 0xffff3df8995039ec : ldr x21, [x24,#120] include/linux/compiler.h: 294 0xffff3df8995039f0 : ldr x1, [x21,x0] kernel/trace/trace_kprobe.c 1308: head = this_cpu_ptr(call->perf_events); 1309: if (hlist_empty(head)) 1310: \treturn 0; crash> struct trace_event_call -o struct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ... } crash> struct trace_event_call ffffaf015340e528 struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ... } Race Condition Analysis: The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)← KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL) Problem: 1. CPU0 executes (1) assigning tp_event->perf_events = list 2. CPU0 executes (2) enabling kprobe functionality via class->reg() 3. CPU1 triggers and reaches kprobe_dispatcher 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed) 5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULL CPU1 sees that kprobe functionality is enabled but does not see that perf_events has been assigned. Add pairing read an ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40200", "url": "https://ubuntu.com/security/CVE-2025-40200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Squashfs: reject negative file sizes in squashfs_read_inode() Syskaller reports a \"WARNING in ovl_copy_up_file\" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip@squashfs.org.uk: only need to check 64 bit quantity]", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40179", "url": "https://ubuntu.com/security/CVE-2025-40179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: verify orphan file size is not too big In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but large orphan files.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40218", "url": "https://ubuntu.com/security/CVE-2025-40218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr: do not repeat pte_offset_map_lock() until success DAMON's virtual address space operation set implementation (vaddr) calls pte_offset_map_lock() inside the page table walk callback function. This is for reading and writing page table accessed bits. If pte_offset_map_lock() fails, it retries by returning the page table walk callback function with ACTION_AGAIN. pte_offset_map_lock() can continuously fail if the target is a pmd migration entry, though. Hence it could cause an infinite page table walk if the migration cannot be done until the page table walk is finished. This indeed caused a soft lockup when CPU hotplugging and DAMON were running in parallel. Avoid the infinite loop by simply not retrying the page table walk. DAMON is promising only a best-effort accuracy, so missing access to such pages is no problem.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40219", "url": "https://ubuntu.com/security/CVE-2025-40219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs. Since commit 9d16947b7583 (\"PCI: Add global pci_lock_rescan_remove()\") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc (\"PCI/IOV: Factor out sriov_add_vfs()\") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls. On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 \t00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 \t0000000000000001 0000000000000000 0000000000000000 0000000180692828 \t00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2. This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy. Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper. Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.", "cve_priority": "medium", "cve_public_date": "2025-12-04 15:15:00 UTC" }, { "cve": "CVE-2025-40193", "url": "https://ubuntu.com/security/CVE-2025-40193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xtensa: simdisk: add input size check in proc_write_simdisk A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash. This follows the same pattern as commit ee76746387f6 (\"netdevsim: prevent bad user input in nsim_dev_health_break_write()\")", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40204", "url": "https://ubuntu.com/security/CVE-2025-40204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40192", "url": "https://ubuntu.com/security/CVE-2025-40192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"ipmi: fix msg stack when IPMI is disconnected\" This reverts commit c608966f3f9c2dca596967501d00753282b395fc. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40188", "url": "https://ubuntu.com/security/CVE-2025-40188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pwm: berlin: Fix wrong register in suspend/resume The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40201", "url": "https://ubuntu.com/security/CVE-2025-40201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40194", "url": "https://ubuntu.com/security/CVE-2025-40194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40205", "url": "https://ubuntu.com/security/CVE-2025-40205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid potential out-of-bounds in btrfs_encode_fh() The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40160", "url": "https://ubuntu.com/security/CVE-2025-40160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/events: Return -EEXIST for bound VIRQs Change find_virq() to return -EEXIST when a VIRQ is bound to a different CPU than the one passed in. With that, remove the BUG_ON() from bind_virq_to_irq() to propogate the error upwards. Some VIRQs are per-cpu, but others are per-domain or global. Those must be bound to CPU0 and can then migrate elsewhere. The lookup for per-domain and global will probably fail when migrated off CPU 0, especially when the current CPU is tracked. This now returns -EEXIST instead of BUG_ON(). A second call to bind a per-domain or global VIRQ is not expected, but make it non-fatal to avoid trying to look up the irq, since we don't know which per_cpu(virq_to_irq) it will be in.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40206", "url": "https://ubuntu.com/security/CVE-2025-40206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_objref: validate objref and objrefmap expressions Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls: BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12) [...] Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 [...] Implement objref and objrefmap expression validate functions. Currently, only NFT_OBJECT_SYNPROXY object type requires validation. This will also handle a jump to a chain using a synproxy object from the OUTPUT hook. Now when trying to reference a synproxy object in the OUTPUT hook, nft will produce the following error: synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40183", "url": "https://ubuntu.com/security/CVE-2025-40183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6} Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40187", "url": "https://ubuntu.com/security/CVE-2025-40187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function.", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40111", "url": "https://ubuntu.com/security/CVE-2025-40111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix Use-after-free in validation Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.", "cve_priority": "medium", "cve_public_date": "2025-11-12 02:15:00 UTC" }, { "cve": "CVE-2025-40110", "url": "https://ubuntu.com/security/CVE-2025-40110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a null-ptr access in the cursor snooper Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it. vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean \"no surface\", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it. Fixes unchecked null-ptr reference in the snooping code.", "cve_priority": "medium", "cve_public_date": "2025-11-12 02:15:00 UTC" }, { "cve": "CVE-2025-40001", "url": "https://ubuntu.com/security/CVE-2025-40001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: mvsas: Fix use-after-free bugs in mvs_work_queue During the detaching of Marvell's SAS/SATA controller, the original code calls cancel_delayed_work() in mvs_free() to cancel the delayed work item mwq->work_q. However, if mwq->work_q is already running, the cancel_delayed_work() may fail to cancel it. This can lead to use-after-free scenarios where mvs_free() frees the mvs_info while mvs_work_queue() is still executing and attempts to access the already-freed mvs_info. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work item completes before the mvs_info is deallocated. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2025-10-18 08:15:00 UTC" }, { "cve": "CVE-2025-40207", "url": "https://ubuntu.com/security/CVE-2025-40207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try() v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().", "cve_priority": "medium", "cve_public_date": "2025-11-12 22:15:00 UTC" }, { "cve": "CVE-2025-40031", "url": "https://ubuntu.com/security/CVE-2025-40031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: fix register_shm_helper() In register_shm_helper(), fix incorrect error handling for a call to iov_iter_extract_pages(). A case is missing for when iov_iter_extract_pages() only got some pages and return a number larger than 0, but not the requested amount. This fixes a possible NULL pointer dereference following a bad input from ioctl(TEE_IOC_SHM_REGISTER) where parts of the buffer isn't mapped.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40037", "url": "https://ubuntu.com/security/CVE-2025-40037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: simplefb: Fix use after free in simplefb_detach_genpds() The pm_domain cleanup can not be devres managed as it uses struct simplefb_par which is allocated within struct fb_info by framebuffer_alloc(). This allocation is explicitly freed by unregister_framebuffer() in simplefb_remove(). Devres managed cleanup runs after the device remove call and thus can no longer access struct simplefb_par. Call simplefb_detach_genpds() explicitly from simplefb_destroy() like the cleanup functions for clocks and regulators. Fixes an use after free on M2 Mac mini during aperture_remove_conflicting_devices() using the downstream asahi kernel with Debian's kernel config. For unknown reasons this started to consistently dereference an invalid pointer in v6.16.3 based kernels. [ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220 [ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227 [ 6.750697] [ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY [ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC [ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT) [ 6.752189] Call trace: [ 6.752190] show_stack+0x34/0x98 (C) [ 6.752194] dump_stack_lvl+0x60/0x80 [ 6.752197] print_report+0x17c/0x4d8 [ 6.752201] kasan_report+0xb4/0x100 [ 6.752206] __asan_report_load4_noabort+0x20/0x30 [ 6.752209] simplefb_detach_genpds+0x58/0x220 [ 6.752213] devm_action_release+0x50/0x98 [ 6.752216] release_nodes+0xd0/0x2c8 [ 6.752219] devres_release_all+0xfc/0x178 [ 6.752221] device_unbind_cleanup+0x28/0x168 [ 6.752224] device_release_driver_internal+0x34c/0x470 [ 6.752228] device_release_driver+0x20/0x38 [ 6.752231] bus_remove_device+0x1b0/0x380 [ 6.752234] device_del+0x314/0x820 [ 6.752238] platform_device_del+0x3c/0x1e8 [ 6.752242] platform_device_unregister+0x20/0x50 [ 6.752246] aperture_detach_platform_device+0x1c/0x30 [ 6.752250] aperture_detach_devices+0x16c/0x290 [ 6.752253] aperture_remove_conflicting_devices+0x34/0x50 ... [ 6.752343] [ 6.967409] Allocated by task 62: [ 6.970724] kasan_save_stack+0x3c/0x70 [ 6.974560] kasan_save_track+0x20/0x40 [ 6.978397] kasan_save_alloc_info+0x40/0x58 [ 6.982670] __kasan_kmalloc+0xd4/0xd8 [ 6.986420] __kmalloc_noprof+0x194/0x540 [ 6.990432] framebuffer_alloc+0xc8/0x130 [ 6.994444] simplefb_probe+0x258/0x2378 ... [ 7.054356] [ 7.055838] Freed by task 227: [ 7.058891] kasan_save_stack+0x3c/0x70 [ 7.062727] kasan_save_track+0x20/0x40 [ 7.066565] kasan_save_free_info+0x4c/0x80 [ 7.070751] __kasan_slab_free+0x6c/0xa0 [ 7.074675] kfree+0x10c/0x380 [ 7.077727] framebuffer_release+0x5c/0x90 [ 7.081826] simplefb_destroy+0x1b4/0x2c0 [ 7.085837] put_fb_info+0x98/0x100 [ 7.089326] unregister_framebuffer+0x178/0x320 [ 7.093861] simplefb_remove+0x3c/0x60 [ 7.097611] platform_remove+0x60/0x98 [ 7.101361] device_remove+0xb8/0x160 [ 7.105024] device_release_driver_internal+0x2fc/0x470 [ 7.110256] device_release_driver+0x20/0x38 [ 7.114529] bus_remove_device+0x1b0/0x380 [ 7.118628] device_del+0x314/0x820 [ 7.122116] platform_device_del+0x3c/0x1e8 [ 7.126302] platform_device_unregister+0x20/0x50 [ 7.131012] aperture_detach_platform_device+0x1c/0x30 [ 7.136157] aperture_detach_devices+0x16c/0x290 [ 7.140779] aperture_remove_conflicting_devices+0x34/0x50 ...", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40047", "url": "https://ubuntu.com/security/CVE-2025-40047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: always prune wait queue entry in io_waitid_wait() For a successful return, always remove our entry from the wait queue entry list. Previously this was skipped if a cancelation was in progress, but this can race with another invocation of the wait queue entry callback.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40057", "url": "https://ubuntu.com/security/CVE-2025-40057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ptp: Add a upper bound on max_vclocks syzbot reported WARNING in max_vclocks_store. This occurs when the argument max is too large for kcalloc to handle. Extend the guard to guard against values that are too large for kcalloc", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40058", "url": "https://ubuntu.com/security/CVE-2025-40058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Disallow dirty tracking if incoherent page walk Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work. The Intel VT-d specification, Section 3.10 \"Snoop Behavior\" states: \"Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault.\" To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40059", "url": "https://ubuntu.com/security/CVE-2025-40059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: Fix incorrect handling for return value of devm_kzalloc The return value of devm_kzalloc could be an null pointer, use \"!desc.pdata\" to fix incorrect handling return value of devm_kzalloc.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40155", "url": "https://ubuntu.com/security/CVE-2025-40155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: debugfs: Fix legacy mode page table dump logic In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like: Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtable_walk_level+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: pgtable_walk_level+0x88/0x150 domain_translation_struct_show.isra.0+0x2d9/0x300 dev_domain_translation_struct_show+0x20/0x40 seq_read_iter+0x12d/0x490 ... Avoid walking the page table if TT is not 00b or 01b.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-40079", "url": "https://ubuntu.com/security/CVE-2025-40079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Sign extend struct ops return values properly The ns_bpf_qdisc selftest triggers a kernel panic: Unable to handle kernel paging request at virtual address ffffffffa38dbf58 Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000 [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000 Oops [#1] Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)] CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G W OE 6.17.0-rc1-g2465bb83e0b4 #1 NONE Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024 epc : __qdisc_run+0x82/0x6f0 ra : __qdisc_run+0x6e/0x6f0 epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550 gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180 t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0 s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001 a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000 a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049 s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000 s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0 s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000 s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000 t5 : 0000000000000000 t6 : ff60000093a6a8b6 status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d [] __qdisc_run+0x82/0x6f0 [] __dev_queue_xmit+0x4c0/0x1128 [] neigh_resolve_output+0xd0/0x170 [] ip6_finish_output2+0x226/0x6c8 [] ip6_finish_output+0x10c/0x2a0 [] ip6_output+0x5e/0x178 [] ip6_xmit+0x29a/0x608 [] inet6_csk_xmit+0xe6/0x140 [] __tcp_transmit_skb+0x45c/0xaa8 [] tcp_connect+0x9ce/0xd10 [] tcp_v6_connect+0x4ac/0x5e8 [] __inet_stream_connect+0xd8/0x318 [] inet_stream_connect+0x3e/0x68 [] __sys_connect_file+0x50/0x88 [] __sys_connect+0x96/0xc8 [] __riscv_sys_connect+0x20/0x30 [] do_trap_ecall_u+0x256/0x378 [] handle_exception+0x14a/0x156 Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709 ---[ end trace 0000000000000000 ]--- The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires RISC-V ABI. So let's sign extend struct ops return values according to the function model and RISC-V ABI([0]). [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2025-40000", "url": "https://ubuntu.com/security/CVE-2025-40000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait() There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to access already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 It is a consequence of a race between the waiting and the signaling side of the completion: Waiting thread Completing thread rtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40026", "url": "https://ubuntu.com/security/CVE-2025-40026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended \"recipient\") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ", "cve_priority": "medium", "cve_public_date": "2025-10-28 10:15:00 UTC" }, { "cve": "CVE-2025-40027", "url": "https://ubuntu.com/security/CVE-2025-40027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix double req put in p9_fd_cancelled Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__list_del_entry include/linux/list.h:137 [inline] RIP: 0010:list_del include/linux/list.h:148 [inline] RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734 Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ... Commit 74d6a5d56629 (\"9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work\") fixes a concurrency issue in the 9p filesystem client where the req_list could be deleted simultaneously by both p9_read_work and p9_fd_cancelled functions, but for the case where req->status equals REQ_STATUS_RCVD. Update the check for req->status in p9_fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [updated the check from status == RECV || status == ERROR to status != SENT]", "cve_priority": "medium", "cve_public_date": "2025-10-28 10:15:00 UTC" }, { "cve": "CVE-2025-40109", "url": "https://ubuntu.com/security/CVE-2025-40109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present Ensure that set_ent is always set since only drbg provides it.", "cve_priority": "medium", "cve_public_date": "2025-11-09 05:15:00 UTC" }, { "cve": "CVE-2025-38105", "url": "https://ubuntu.com/security/CVE-2025-38105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too.", "cve_priority": "medium", "cve_public_date": "2025-07-03 09:15:00 UTC" }, { "cve": "CVE-2025-40107", "url": "https://ubuntu.com/security/CVE-2025-40107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d (\"can: mcp251x: fix resume from sleep before interface was brought up\"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks.", "cve_priority": "medium", "cve_public_date": "2025-11-03 13:15:00 UTC" }, { "cve": "CVE-2025-39995", "url": "https://ubuntu.com/security/CVE-2025-39995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe The state->timer is a cyclic timer that schedules work_i2c_poll and delayed_work_enable_hotplug, while rearming itself. Using timer_delete() fails to guarantee the timer isn't still running when destroyed, similarly cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has terminated if already executing. During probe failure after timer initialization, these may continue running as orphans and reference the already-freed tc358743_state object through tc358743_irq_poll_timer. The following is the trace captured by KASAN. BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __pfx_sched_balance_find_src_group+0x10/0x10 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? tmigr_update_events+0x280/0x740 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x98/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_node_track_caller_noprof+0x198/0x430 devm_kmalloc+0x7b/0x1e0 tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 141: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 release_nodes+0xa4/0x100 devres_release_group+0x1b2/0x380 i2c_device_probe+0x694/0x880 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __device_attach_driver+0x174/0x220 bus_for_each_drv+0x100/0x190 __device_attach+0x206/0x370 bus_probe_device+0x123/0x170 device_add+0xd25/0x1470 i2c_new_client_device+0x7a0/0xcd0 do_one_initcall+0x89/0x300 do_init_module+0x29d/0x7f0 load_module+0x4f48/0x69e0 init_module_from_file+0xe4/0x150 idempotent_init_module+0x320/0x670 __x64_sys_finit_module+0xbd/0x120 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace timer_delete() with timer_delete_sync() and cancel_delayed_work() with cancel_delayed_work_sync() to ensure proper termination of timer and work items before resource cleanup. This bug was initially identified through static analysis. For reproduction and testing, I created a functional emulation of the tc358743 device via a kernel module and introduced faults through the debugfs interface.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39994", "url": "https://ubuntu.com/security/CVE-2025-39994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: tuner: xc5000: Fix use-after-free in xc5000_release The original code uses cancel_delayed_work() in xc5000_release(), which does not guarantee that the delayed work item timer_sleep has fully completed if it was already running. This leads to use-after-free scenarios where xc5000_release() may free the xc5000_priv while timer_sleep is still active and attempts to dereference the xc5000_priv. A typical race condition is illustrated below: CPU 0 (release thread) | CPU 1 (delayed work callback) xc5000_release() | xc5000_do_timer_sleep() cancel_delayed_work() | hybrid_tuner_release_state(priv) | kfree(priv) | | priv = container_of() // UAF Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the timer_sleep is properly canceled before the xc5000_priv memory is deallocated. A deadlock concern was considered: xc5000_release() is called in a process context and is not holding any locks that the timer_sleep work item might also need. Therefore, the use of the _sync() variant is safe here. This bug was initially identified through static analysis. [hverkuil: fix typo in Subject: tunner -> tuner]", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39991", "url": "https://ubuntu.com/security/CVE-2025-39991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load() If ab->fw.m3_data points to data, then fw pointer remains null. Further, if m3_mem is not allocated, then fw is dereferenced to be passed to ath11k_err function. Replace fw->size by m3_len. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39992", "url": "https://ubuntu.com/security/CVE-2025-39992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap())\t\t\tswapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> \tcopy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). \t\t\t\t 4) swapoff is tried on the \t\t\t\t\t'mm' added to the 'mmlist' as \t\t\t\t\tpart of the 2. \t\t\t\t 5) unuse_mm(), that iterates \t\t\t\t\tthrough the vma's of this 'mm' \t\t\t\t\twill hit the non-NULL zero entry \t\t\t\t\tand operating on this zero entry \t\t\t\t\tas a vma is resulting into the \t\t\t\t\toops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40013", "url": "https://ubuntu.com/security/CVE-2025-40013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: audioreach: fix potential null pointer dereference It is possible that the topology parsing function audioreach_widget_load_module_common() could return NULL or an error pointer. Add missing NULL check so that we do not dereference it.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40016", "url": "https://ubuntu.com/security/CVE-2025-40016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` If we add a new entity with id 0 or a duplicated ID, it will be marked as UVC_INVALID_ENTITY_ID. In a previous attempt commit 3dd075fe8ebb (\"media: uvcvideo: Require entities to have a non-zero unique ID\"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39996", "url": "https://ubuntu.com/security/CVE-2025-39996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove The original code uses cancel_delayed_work() in flexcop_pci_remove(), which does not guarantee that the delayed work item irq_check_work has fully completed if it was already running. This leads to use-after-free scenarios where flexcop_pci_remove() may free the flexcop_device while irq_check_work is still active and attempts to dereference the device. A typical race condition is illustrated below: CPU 0 (remove) | CPU 1 (delayed work callback) flexcop_pci_remove() | flexcop_pci_irq_check_work() cancel_delayed_work() | flexcop_device_kfree(fc_pci->fc_dev) | | fc = fc_pci->fc_dev; // UAF This is confirmed by a KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff8880093aa8c8 by task bash/135 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x1be/0x460 flexcop_device_kmalloc+0x54/0xe0 flexcop_pci_probe+0x1f/0x9d0 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 135: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 flexcop_device_kfree+0x32/0x50 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled and any executing delayed work has finished before the device memory is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced artificial delays within the flexcop_pci_irq_check_work() function to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39998", "url": "https://ubuntu.com/security/CVE-2025-39998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: target_core_configfs: Add length check to avoid buffer overflow A buffer overflow arises from the usage of snprintf to write into the buffer \"buf\" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40009", "url": "https://ubuntu.com/security/CVE-2025-40009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: check p->vec_buf for NULL When the PAGEMAP_SCAN ioctl is invoked with vec_len = 0 reaches pagemap_scan_backout_range(), kernel panics with null-ptr-deref: [ 44.936808] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.937797] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 44.938391] CPU: 1 UID: 0 PID: 2480 Comm: reproducer Not tainted 6.17.0-rc6 #22 PREEMPT(none) [ 44.939062] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.939935] RIP: 0010:pagemap_scan_thp_entry.isra.0+0x741/0xa80 [ 44.946828] Call Trace: [ 44.947030] [ 44.949219] pagemap_scan_pmd_entry+0xec/0xfa0 [ 44.952593] walk_pmd_range.isra.0+0x302/0x910 [ 44.954069] walk_pud_range.isra.0+0x419/0x790 [ 44.954427] walk_p4d_range+0x41e/0x620 [ 44.954743] walk_pgd_range+0x31e/0x630 [ 44.955057] __walk_page_range+0x160/0x670 [ 44.956883] walk_page_range_mm+0x408/0x980 [ 44.958677] walk_page_range+0x66/0x90 [ 44.958984] do_pagemap_scan+0x28d/0x9c0 [ 44.961833] do_pagemap_cmd+0x59/0x80 [ 44.962484] __x64_sys_ioctl+0x18d/0x210 [ 44.962804] do_syscall_64+0x5b/0x290 [ 44.963111] entry_SYSCALL_64_after_hwframe+0x76/0x7e vec_len = 0 in pagemap_scan_init_bounce_buffer() means no buffers are allocated and p->vec_buf remains set to NULL. This breaks an assumption made later in pagemap_scan_backout_range(), that page_region is always allocated for p->vec_buf_index. Fix it by explicitly checking p->vec_buf for NULL before dereferencing. Other sites that might run into same deref-issue are already (directly or transitively) protected by checking p->vec_buf. Note: From PAGEMAP_SCAN man page, it seems vec_len = 0 is valid when no output is requested and it's only the side effects caller is interested in, hence it passes check in pagemap_scan_get_args(). This issue was found by syzkaller.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39973", "url": "https://ubuntu.com/security/CVE-2025-39973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: add validation for ring_len param The `ring_len` parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation. To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-38709", "url": "https://ubuntu.com/security/CVE-2025-38709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: loop: Avoid updating block size under exclusive owner Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size. Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.", "cve_priority": "medium", "cve_public_date": "2025-09-04 16:15:00 UTC" }, { "cve": "CVE-2025-39967", "url": "https://ubuntu.com/security/CVE-2025-39967", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix integer overflow in fbcon_do_set_font Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters. The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying. Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40006", "url": "https://ubuntu.com/security/CVE-2025-40006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix folio is still mapped when deleted Migration may be raced with fallocating hole. remove_inode_single_folio will unmap the folio if the folio is still mapped. However, it's called without folio lock. If the folio is migrated and the mapped pte has been converted to migration entry, folio_mapped() returns false, and won't unmap it. Due to extra refcount held by remove_inode_single_folio, migration fails, restores migration entry to normal pte, and the folio is mapped again. As a result, we triggered BUG in filemap_unaccount_folio. The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):\"my_hugepage_file\" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380 Hold folio lock before checking if the folio is mapped to avold race with migration.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40008", "url": "https://ubuntu.com/security/CVE-2025-40008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kmsan: fix out-of-bounds access to shadow memory Running sha224_kunit on a KMSAN-enabled kernel results in a crash in kmsan_internal_set_shadow_origin(): BUG: unable to handle page fault for address: ffffbc3840291000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1810067 P4D 1810067 PUD 192d067 PMD 3c17067 PTE 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 81 Comm: kunit_try_catch Tainted: G N 6.17.0-rc3 #10 PREEMPT(voluntary) Tainted: [N]=TEST Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmsan_internal_set_shadow_origin+0x91/0x100 [...] Call Trace: __msan_memset+0xee/0x1a0 sha224_final+0x9e/0x350 test_hash_buffer_overruns+0x46f/0x5f0 ? kmsan_get_shadow_origin_ptr+0x46/0xa0 ? __pfx_test_hash_buffer_overruns+0x10/0x10 kunit_try_run_case+0x198/0xa00 This occurs when memset() is called on a buffer that is not 4-byte aligned and extends to the end of a guard page, i.e. the next page is unmapped. The bug is that the loop at the end of kmsan_internal_set_shadow_origin() accesses the wrong shadow memory bytes when the address is not 4-byte aligned. Since each 4 bytes are associated with an origin, it rounds the address and size so that it can access all the origins that contain the buffer. However, when it checks the corresponding shadow bytes for a particular origin, it incorrectly uses the original unrounded shadow address. This results in reads from shadow memory beyond the end of the buffer's shadow memory, which crashes when that memory is not mapped. To fix this, correctly align the shadow address before accessing the 4 shadow bytes corresponding to each origin.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40010", "url": "https://ubuntu.com/security/CVE-2025-40010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix potential null pointer dereference in afs_put_server afs_put_server() accessed server->debug_id before the NULL check, which could lead to a null pointer dereference. Move the debug_id assignment, ensuring we never dereference a NULL server pointer.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-40021", "url": "https://ubuntu.com/security/CVE-2025-40021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: dynevent: Add a missing lockdown check on dynevent Since dynamic_events interface on tracefs is compatible with kprobe_events and uprobe_events, it should also check the lockdown status and reject if it is set.", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39968", "url": "https://ubuntu.com/security/CVE-2025-39968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: add max boundary check for VF filters There is no check for max filters that VF can request. Add it.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39969", "url": "https://ubuntu.com/security/CVE-2025-39969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix validation of VF state in get resources VF state I40E_VF_STATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources. Use I40E_VF_STATE_RESOURCES_LOADED that is set only in i40e_vc_get_vf_resources_msg() and cleared during reset.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39970", "url": "https://ubuntu.com/security/CVE-2025-39970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix input validation logic for action_meta Fix condition to check 'greater or equal' to prevent OOB dereference.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39971", "url": "https://ubuntu.com/security/CVE-2025-39971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg().", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39972", "url": "https://ubuntu.com/security/CVE-2025-39972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in i40e_validate_queue_map Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map().", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39977", "url": "https://ubuntu.com/security/CVE-2025-39977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent use-after-free during requeue-PI syzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL); In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization. This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section. Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated. Read futex_q::task before updating the requeue state, use it for the following wakeup.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40011", "url": "https://ubuntu.com/security/CVE-2025-40011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix null dereference in hdmi teardown pci_set_drvdata sets the value of pdev->driver_data to NULL, after which the driver_data obtained from the same dev is dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is extracted from it. To prevent this, swap these calls. Found by Linux Verification Center (linuxtesting.org) with Svacer.", "cve_priority": "medium", "cve_public_date": "2025-10-20 16:15:00 UTC" }, { "cve": "CVE-2025-39978", "url": "https://ubuntu.com/security/CVE-2025-39978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow() This code calls kfree_rcu(new_node, rcu) and then dereferences \"new_node\" and then dereferences it on the next line. Two lines later, we take a mutex so I don't think this is an RCU safe region. Re-order it to do the dereferences before queuing up the free.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39980", "url": "https://ubuntu.com/security/CVE-2025-39980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: Forbid FDB status change while nexthop is in a group The kernel forbids the creation of non-FDB nexthop groups with FDB nexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops. And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops. However, as long as no routes are pointing to a non-FDB nexthop group, the kernel allows changing the type of a nexthop from FDB to non-FDB and vice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0 This configuration is invalid and can result in a NPD [1] since FDB nexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1 Fix by preventing nexthop FDB status change while the nexthop is in a group: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group. [1] BUG: kernel NULL pointer dereference, address: 00000000000003c0 [...] Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:fib_lookup_good_nhc+0x1e/0x80 [...] Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40024", "url": "https://ubuntu.com/security/CVE-2025-40024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost: Take a reference on the task in struct vhost_task. vhost_task_create() creates a task and keeps a reference to its task_struct. That task may exit early via a signal and its task_struct will be released. A pending vhost_task_wake() will then attempt to wake the task and access a task_struct which is no longer there. Acquire a reference on the task_struct while creating the thread and release the reference while the struct vhost_task itself is removed. If the task exits early due to a signal, then the vhost_task_wake() will still access a valid task_struct. The wake is safe and will be skipped in this case.", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39982", "url": "https://ubuntu.com/security/CVE-2025-39982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync This fixes the following UFA in hci_acl_create_conn_sync where a connection still pending is command submission (conn->state == BT_OPEN) maybe freed, also since this also can happen with the likes of hci_le_create_conn_sync fix it as well: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541 CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci3 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x230 mm/kasan/report.c:480 kasan_report+0x118/0x150 mm/kasan/report.c:593 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245 Allocated by task 123736: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline] hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x54b/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 103680: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x18e/0x440 mm/slub.c:4842 device_release+0x9c/0x1c0 kobject_cleanup lib/kobject.c:689 [inline] kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x22b/0x480 lib/kobject.c:737 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline] hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199 hci_event_func net/bluetooth/hci_event.c:7477 [inline] hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-40020", "url": "https://ubuntu.com/security/CVE-2025-40020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: fix shift-out-of-bounds issue Explicitly uses a 64-bit constant when the number of bits used for its shifting is 32 (which is the case for PC CAN FD interfaces supported by this driver). [mkl: update subject, apply manually]", "cve_priority": "medium", "cve_public_date": "2025-10-24 13:15:00 UTC" }, { "cve": "CVE-2025-39985", "url": "https://ubuntu.com/security/CVE-2025-39985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the mcba_usb driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on these lines: \tusb_msg.dlc = cf->len; \tmemcpy(usb_msg.data, cf->data, usb_msg.dlc); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39986", "url": "https://ubuntu.com/security/CVE-2025-39986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, sun4ican_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on this line: \tdlc = cf->len; Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs a couple line below when doing: \tfor (i = 0; i < dlc; i++) \t\twritel(cf->data[i], priv->base + (dreg + i * 4)); Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39987", "url": "https://ubuntu.com/security/CVE-2025-39987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: hi311x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)) to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. The driver will consume frame->len as-is with no further checks. This can result in a buffer overflow later on in hi3110_hw_tx() on this line: \tmemcpy(buf + HI3110_FIFO_EXT_DATA_OFF, \t frame->data, frame->len); Here, frame->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39988", "url": "https://ubuntu.com/security/CVE-2025-39988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow Sending an PF_PACKET allows to bypass the CAN framework logic and to directly reach the xmit() function of a CAN driver. The only check which is performed by the PF_PACKET framework is to make sure that skb->len fits the interface's MTU. Unfortunately, because the etas_es58x driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example: $ ip link set can0 mtu 9999 After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol: \tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL)); to inject a malicious CAN XL frames. For example: \tstruct canxl_frame frame = { \t\t.flags = 0xff, \t\t.len = 2048, \t}; The CAN drivers' xmit() function are calling can_dev_dropped_skb() to check that the skb is valid, unfortunately under above conditions, the malicious packet is able to go through can_dev_dropped_skb() checks: 1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities). 2. the length is a valid CAN XL length. And so, es58x_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN(FD) frame. This can result in a buffer overflow. For example, using the es581.4 variant, the frame will be dispatched to es581_4_tx_can_msg(), go through the last check at the beginning of this function: \tif (can_is_canfd_skb(skb)) \t\treturn -EMSGSIZE; and reach this line: \tmemcpy(tx_can_msg->data, cf->data, cf->len); Here, cf->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs! Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU or CANFD_MTU (depending on the device capabilities). By fixing the root cause, this prevents the buffer overflow.", "cve_priority": "medium", "cve_public_date": "2025-10-15 08:15:00 UTC" }, { "cve": "CVE-2025-39932", "url": "https://ubuntu.com/security/CVE-2025-39932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work) In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again. I actually just hit the case using rxe: WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10 [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ... It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39940", "url": "https://ubuntu.com/security/CVE-2025-39940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-stripe: fix a possible integer overflow There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39948", "url": "https://ubuntu.com/security/CVE-2025-39948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix Rx page leak on multi-buffer frames The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver. It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed. If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf(). Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc. The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page. Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with \"jumbo frames\" used by 9K MTU. To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts(). Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() on the last buffer of the frame indicating the end of packet. For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss. The xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame. Move the increment of the ntc local variable to ensure its updated *before* all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic requires the index of the element just after the current frame. Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rx_ring.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39950", "url": "https://ubuntu.com/security/CVE-2025-39950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR A NULL pointer dereference can occur in tcp_ao_finish_connect() during a connect() system call on a socket with a TCP-AO key added and TCP_REPAIR enabled. The function is called with skb being NULL and attempts to dereference it on tcp_hdr(skb)->seq without a prior skb validation. Fix this by checking if skb is NULL before dereferencing it. The commentary is taken from bpf_skops_established(), which is also called in the same flow. Unlike the function being patched, bpf_skops_established() validates the skb before dereferencing it. int main(void){ \tstruct sockaddr_in sockaddr; \tstruct tcp_ao_add tcp_ao; \tint sk; \tint one = 1; \tmemset(&sockaddr,'\\0',sizeof(sockaddr)); \tmemset(&tcp_ao,'\\0',sizeof(tcp_ao)); \tsk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); \tsockaddr.sin_family = AF_INET; \tmemcpy(tcp_ao.alg_name,\"cmac(aes128)\",12); \tmemcpy(tcp_ao.key,\"ABCDEFGHABCDEFGH\",16); \ttcp_ao.keylen = 16; \tmemcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); \tsetsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao, \tsizeof(tcp_ao)); \tsetsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one)); \tsockaddr.sin_family = AF_INET; \tsockaddr.sin_port = htobe16(123); \tinet_aton(\"127.0.0.1\", &sockaddr.sin_addr); \tconnect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr)); return 0; } $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall $ unshare -Urn BUG: kernel NULL pointer dereference, address: 00000000000000b6 PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39961", "url": "https://ubuntu.com/security/CVE-2025-39961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd/pgtbl: Fix possible race while increase page table level The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] \t\t\t\t\t Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.", "cve_priority": "medium", "cve_public_date": "2025-10-09 13:15:00 UTC" }, { "cve": "CVE-2025-22106", "url": "https://ubuntu.com/security/CVE-2025-22106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: unregister xdp rxq info in the reset path vmxnet3 does not unregister xdp rxq info in the vmxnet3_reset_work() code path as vmxnet3_rq_destroy() is not invoked in this code path. So, we get below message with a backtrace. Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 __xdp_rxq_info_reg+0x93/0xf0 This patch fixes the problem by moving the unregister code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39934", "url": "https://ubuntu.com/security/CVE-2025-39934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39937", "url": "https://ubuntu.com/security/CVE-2025-39937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer Since commit 7d5e9737efda (\"net: rfkill: gpio: get the name and type from device property\") rfkill_find_type() gets called with the possibly uninitialized \"const char *type_name;\" local variable. On x86 systems when rfkill-gpio binds to a \"BCM4752\" or \"LNV4752\" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data; and there is no \"type\" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash. rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL. Note likely sofar this has not been caught because: 1. Not many x86 machines actually have a \"BCM4752\"/\"LNV4752\" acpi_device 2. The stack happened to contain NULL where type_name is stored", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39938", "url": "https://ubuntu.com/security/CVE-2025-39938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed If earlier opening of source graph fails (e.g. ADSP rejects due to incorrect audioreach topology), the graph is closed and \"dai_data->graph[dai->id]\" is assigned NULL. Preparing the DAI for sink graph continues though and next call to q6apm_lpass_dai_prepare() receives dai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39942", "url": "https://ubuntu.com/security/CVE-2025-39942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size This is inspired by the check for data_offset + data_length.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39943", "url": "https://ubuntu.com/security/CVE-2025-39943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: validate data_offset and data_length field of smb_direct_data_transfer If data_offset and data_length of smb_direct_data_transfer struct are invalid, out of bounds issue could happen. This patch validate data_offset and data_length field in recv_done.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39944", "url": "https://ubuntu.com/security/CVE-2025-39944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp() The original code relies on cancel_delayed_work() in otx2_ptp_destroy(), which does not ensure that the delayed work item synctstamp_work has fully completed if it was already running. This leads to use-after-free scenarios where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp(). Furthermore, the synctstamp_work is cyclic, the likelihood of triggering the bug is nonnegligible. A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAF This is confirmed by a KASAN report: BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800aa09a18 by task bash/136 ... Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled before the otx2_ptp is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced artificial delays within the otx2_sync_tstamp() function to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39945", "url": "https://ubuntu.com/security/CVE-2025-39945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cnic: Fix use-after-free bugs in cnic_delete_task The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39955", "url": "https://ubuntu.com/security/CVE-2025-39955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect(). syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk in the TCP_ESTABLISHED state. [0] syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destination As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes it to TCP_CLOSE and makes connect() possible, which restarts timers. Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the retransmit timer triggered the warning and the intended packet was not retransmitted. Let's call reqsk_fastopen_remove() in tcp_disconnect(). [0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) ", "cve_priority": "medium", "cve_public_date": "2025-10-09 10:15:00 UTC" }, { "cve": "CVE-2025-39947", "url": "https://ubuntu.com/security/CVE-2025-39947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Harden uplink netdev access against device unbind The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39949", "url": "https://ubuntu.com/security/CVE-2025-39949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qed: Don't collect too many protection override GRC elements In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer. This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESS where \"ADDRESS\" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure. The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783 or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663 Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39951", "url": "https://ubuntu.com/security/CVE-2025-39951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: virtio_uml: Fix use-after-free after put_device in probe When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39953", "url": "https://ubuntu.com/security/CVE-2025-39953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup: split cgroup_destroy_wq into 3 workqueues A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction. Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio Call Trace: \tcgroup_lock_and_drain_offline+0x14c/0x1e8 \tcgroup_destroy_root+0x3c/0x2c0 \tcss_free_rwork_fn+0x248/0x338 \tprocess_one_work+0x16c/0x3b8 \tworker_thread+0x22c/0x3b0 \tkthread+0xec/0x100 \tret_from_fork+0x10/0x20 Root Cause: CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues \t\t\t\t// cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1) Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation This separation eliminates blocking in the CSS free path while waiting for offline operations to complete. [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39957", "url": "https://ubuntu.com/security/CVE-2025-39957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: increase scan_ies_len for S1G Currently the S1G capability element is not taken into account for the scan_ies_len, which leads to a buffer length validation failure in ieee80211_prep_hw_scan() and subsequent WARN in __ieee80211_start_scan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length.", "cve_priority": "medium", "cve_public_date": "2025-10-09 10:15:00 UTC" }, { "cve": "CVE-2025-39952", "url": "https://ubuntu.com/security/CVE-2025-39952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: avoid buffer overflow in WID string configuration Fix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537) This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2025-39927", "url": "https://ubuntu.com/security/CVE-2025-39927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix race condition validating r_parent before applying state Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39923", "url": "https://ubuntu.com/security/CVE-2025-39923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing. However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2]. Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs. [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/ [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39869", "url": "https://ubuntu.com/security/CVE-2025-39869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map Fix a critical memory allocation bug in edma_setup_from_hw() where queue_priority_map was allocated with insufficient memory. The code declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8), but allocated memory using sizeof(s8) instead of the correct size. This caused out-of-bounds memory writes when accessing: queue_priority_map[i][0] = i; queue_priority_map[i][1] = i; The bug manifested as kernel crashes with \"Oops - undefined instruction\" on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the memory corruption triggered kernel hardening features on Clang. Change the allocation to use sizeof(*queue_priority_map) which automatically gets the correct size for the 2D array structure.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39873", "url": "https://ubuntu.com/security/CVE-2025-39873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKB can_put_echo_skb() takes ownership of the SKB and it may be freed during or after the call. However, xilinx_can xcan_write_frame() keeps using SKB after the call. Fix that by only calling can_put_echo_skb() after the code is done touching the SKB. The tx_lock is held for the entire xcan_write_frame() execution and also on the can_get_echo_skb() side so the order of operations does not matter. An earlier fix commit 3d3c817c3a40 (\"can: xilinx_can: Fix usage of skb memory\") did not move the can_put_echo_skb() call far enough. [mkl: add \"commit\" in front of sha1 in patch description] [mkl: fix indention]", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39911", "url": "https://ubuntu.com/security/CVE-2025-39911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration later than the first, the error path wants to free the IRQs requested so far. However, it uses the wrong dev_id argument for free_irq(), so it does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]--- Use the same dev_id for free_irq() as for request_irq(). I tested this with inserting code to fail intentionally.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39876", "url": "https://ubuntu.com/security/CVE-2025-39876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() The function of_phy_find_device may return NULL, so we need to take care before dereferencing phy_dev.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39881", "url": "https://ubuntu.com/security/CVE-2025-39881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernfs: Fix UAF in polling when open file is released A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism: BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1 psi_trigger_poll+0x3c/0x140 cgroup_pressure_poll+0x70/0xa0 cgroup_file_poll+0x8c/0x100 kernfs_fop_poll+0x11c/0x1c0 ep_item_poll.isra.0+0x188/0x2c0 Allocated by task 1: cgroup_file_open+0x88/0x388 kernfs_fop_open+0x73c/0xaf0 do_dentry_open+0x5fc/0x1200 vfs_open+0xa0/0x3f0 do_open+0x7e8/0xd08 path_openat+0x2fc/0x6b0 do_filp_open+0x174/0x368 Freed by task 8462: cgroup_file_release+0x130/0x1f8 kernfs_drain_open_files+0x17c/0x440 kernfs_drain+0x2dc/0x360 kernfs_show+0x1b8/0x288 cgroup_file_show+0x150/0x268 cgroup_pressure_write+0x1dc/0x340 cgroup_file_write+0x274/0x548 Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroup_file_release() - Frees of->priv through kernfs_drain_open_files() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv epolling\t\t\tdisable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epoll_wait kernfs_fop_poll kernfs_get_active = true\techo 0 > cgroup.pressure ...\t\t\t\tcgroup_file_show \t\t\t\tkernfs_show \t\t\t\t// inactive kn \t\t\t\tkernfs_drain_open_files \t\t\t\tcft->release(of); \t\t\t\tkfree(ctx); \t\t\t\t... kernfs_get_active = false \t\t\t\techo 1 > cgroup.pressure \t\t\t\tkernfs_show \t\t\t\tkernfs_activate_one(kn); kernfs_fop_poll kernfs_get_active = true cgroup_file_poll psi_trigger_poll // UAF ... end: close(fd) To address this issue, introduce kernfs_get_active_of() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfs_get_active() with kernfs_get_active_of() to prevent further operations on released file descriptors.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39909", "url": "https://ubuntu.com/security/CVE-2025-39909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters() Patch series \"mm/damon: avoid divide-by-zero in DAMON module's parameters application\". DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors. Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters. This patch (of 2): During the calculation of 'hot_thres' and 'cold_thres', either 'sample_interval' or 'aggr_interval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggr_interval' is already required to be set no smaller than 'sample_interval' in damon_set_attrs(), only the case where 'sample_interval' is zero needs to be checked.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39916", "url": "https://ubuntu.com/security/CVE-2025-39916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters() When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39877", "url": "https://ubuntu.com/security/CVE-2025-39877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: fix use-after-free in state_show() state_show() reads kdamond->damon_ctx without holding damon_sysfs_lock. This allows a use-after-free race: CPU 0 CPU 1 ----- ----- state_show() damon_sysfs_turn_damon_on() ctx = kdamond->damon_ctx; mutex_lock(&damon_sysfs_lock); damon_destroy_ctx(kdamond->damon_ctx); kdamond->damon_ctx = NULL; mutex_unlock(&damon_sysfs_lock); damon_is_running(ctx); /* ctx is freed */ mutex_lock(&ctx->kdamond_lock); /* UAF */ (The race can also occur with damon_sysfs_kdamonds_rm_dirs() and damon_sysfs_kdamond_release(), which free or replace the context under damon_sysfs_lock.) Fix by taking damon_sysfs_lock before dereferencing the context, mirroring the locking used in pid_show(). The bug has existed since state_show() first accessed kdamond->damon_ctx.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39880", "url": "https://ubuntu.com/security/CVE-2025-39880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix invalid accesses to ceph_connection_v1_info There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use). On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets. con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39883", "url": "https://ubuntu.com/security/CVE-2025-39883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory When I did memory failure tests, below panic occurs: page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 Modules linked in: hwpoison_inject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- The root cause is that unpoison_memory() tries to check the PG_HWPoison flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps: 1.Offline memory block: echo offline > /sys/devices/system/memory/memory12/state 2.Get offlined memory pfn: page-types -b n -rlN 3.Write pfn to unpoison-pfn echo > /sys/kernel/debug/hwpoison/unpoison-pfn This scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail if pfn_to_online_page() == NULL to fix the bug.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39907", "url": "https://ubuntu.com/security/CVE-2025-39907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer Avoid below overlapping mappings by using a contiguous non-cacheable buffer. [ 4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST, overlapping mappings aren't supported [ 4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300 [ 4.097071] Modules linked in: [ 4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1 [ 4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT) [ 4.118824] Workqueue: events_unbound deferred_probe_work_func [ 4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.131624] pc : add_dma_entry+0x23c/0x300 [ 4.135658] lr : add_dma_entry+0x23c/0x300 [ 4.139792] sp : ffff800009dbb490 [ 4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000 [ 4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8 [ 4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20 [ 4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006 [ 4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e [ 4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec [ 4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58 [ 4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000 [ 4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40 [ 4.214185] Call trace: [ 4.216605] add_dma_entry+0x23c/0x300 [ 4.220338] debug_dma_map_sg+0x198/0x350 [ 4.224373] __dma_map_sg_attrs+0xa0/0x110 [ 4.228411] dma_map_sg_attrs+0x10/0x2c [ 4.232247] stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc [ 4.237088] stm32_fmc2_nfc_seq_read_page+0xc8/0x174 [ 4.242127] nand_read_oob+0x1d4/0x8e0 [ 4.245861] mtd_read_oob_std+0x58/0x84 [ 4.249596] mtd_read_oob+0x90/0x150 [ 4.253231] mtd_read+0x68/0xac", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39885", "url": "https://ubuntu.com/security/CVE-2025-39885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix recursive semaphore deadlock in fiemap call syzbot detected a OCFS2 hang due to a recursive semaphore on a FS_IOC_FIEMAP of the extent list on a specially crafted mmap file. context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline] RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline] RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline] RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26 Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89 f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41 RSP: 0018:ffffc9000403f950 EFLAGS: 00050256 RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038 RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060 RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42 R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098 R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5f13850fd9 RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9 RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004 RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0 R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the extent list of this running mmap executable. The user supplied buffer to hold the fiemap information page faults calling ocfs2_page_mkwrite() which will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same semaphore. This recursive semaphore will hold filesystem locks and causes a hang of the fileystem. The ip_alloc_sem protects the inode extent list and size. Release the read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap() and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock on the last extent but simplifies the error path.", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39913", "url": "https://ubuntu.com/security/CVE-2025-39913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork. syzbot reported the splat below. [0] The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytes At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes(). Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN. If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc(). Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork. The \"*copied\" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets \"*copied\" to 0. [0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 ", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39886", "url": "https://ubuntu.com/security/CVE-2025-39886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init() Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example: ... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ... The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event. We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc. As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there. Depends on mm patch \"memcg: skip cgroup_file_notify if spinning is not allowed\": https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/ v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/", "cve_priority": "medium", "cve_public_date": "2025-09-23 06:15:00 UTC" }, { "cve": "CVE-2025-39914", "url": "https://ubuntu.com/security/CVE-2025-39914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Silence warning when chunk allocation fails in trace_pid_write Syzkaller trigger a fault injection warning: WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning. The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-23143", "url": "https://ubuntu.com/security/CVE-2025-23143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod. When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1] Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule At step 3), the CIFS module calls sock_release() for the underlying TCP socket, and it returns quickly. However, the socket remains in FIN_WAIT_1 because incoming FIN packets are dropped. At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sock_release() and it returns, the TCP socket does not die immediately in order to close the connection gracefully. While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sk_lock using sock_lock_init_class_and_name(). Once an incoming packet is processed for the socket or a timer fires, sk->sk_lock is acquired. Then, LOCKDEP checks the lock context in check_wait_context(), where hlock_class() is called to retrieve the lock class. However, since the module has already been unloaded, hlock_class() logs a warning and returns NULL, triggering the null-ptr-deref. If LOCKDEP is enabled, we must ensure that a module calling sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue. Let's hold the module reference in sock_lock_init_class_and_name() and release it when the socket is freed in sk_prot_free(). Note that sock_lock_init() clears sk->sk_owner for svc_create_socket() that calls sock_lock_init_class_and_name() for a listening socket, which clones a socket by sk_clone_lock() without GFP_ZERO. [0]: CIFS_SERVER=\"10.0.0.137\" CIFS_PATH=\"//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST\" DEV=\"enp0s3\" CRED=\"/root/WindowsCredential.txt\" MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire (kernel/ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-05-01 13:15:00 UTC" }, { "cve": "CVE-2025-22124", "url": "https://ubuntu.com/security/CVE-2025-22124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb In clustermd, separate write-intent-bitmaps are used for each cluster node: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal to bitmap->storage.file_pages. Then bitmap_limit will be calculated to 0. md_super_write() will be called with 0 size. That means the first 4k sb area of node 1 will never be updated through filemap_write_page(). This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize. Here use (pg_index % bitmap->storage.file_pages) to make calculation of bitmap_limit correct.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22103", "url": "https://ubuntu.com/security/CVE-2025-22103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer dereference in l3mdev_l3_rcv When delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3s This may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354 This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process like this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops | To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-23133", "url": "https://ubuntu.com/security/CVE-2025-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: update channel list in reg notifier instead reg worker Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list(). But ath11k will immediately execute step 3 after reg_work is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0 Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set, cfg80211 will notify ath11k after step 2 is done. So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3. [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/ Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22113", "url": "https://ubuntu.com/security/CVE-2025-22113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid journaling sb update on error if journal is destroying Presently we always BUG_ON if trying to start a transaction on a journal marked with JBD2_UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for update_super_work to start a transaction after the journal is destroyed eg: (umount) ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super \tflush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT) Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit. Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updates This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc86606) Also, we don't need a similar check in ext4_grp_locked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-22125", "url": "https://ubuntu.com/security/CVE-2025-22125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: don't ignore IO flags If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced. Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks. Fix those problems by keep IO flags from master bio. Fises: f51d46d0e7cb (\"md: add support for REQ_NOWAIT\")", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2025-39899", "url": "https://ubuntu.com/security/CVE-2025-39899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using kmap_local_page(), which requires unmapping in Last-In-First-Out order. The current code maps dst_pte first, then src_pte, but unmaps them in the same order (dst_pte, src_pte), violating the LIFO requirement. This causes the warning in kunmap_local_indexed(): WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c addr \\!= __fix_to_virt(FIX_KMAP_BEGIN + idx) Fix this by reversing the unmap order to respect LIFO ordering. This issue follows the same pattern as similar fixes: - commit eca6828403b8 (\"crypto: skcipher - fix mismatch between mapping and unmapping order\") - commit 8cf57c6df818 (\"nilfs2: eliminate staggered calls to kunmap in nilfs_rename\") Both of which addressed the same fundamental requirement that kmap_local operations must follow LIFO ordering.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39897", "url": "https://ubuntu.com/security/CVE-2025-39897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Add error handling for RX metadata pointer retrieval Add proper error checking for dmaengine_desc_get_metadata_ptr() which can return an error pointer and lead to potential crashes or undefined behaviour if the pointer retrieval fails. Properly handle the error by unmapping DMA buffer, freeing the skb and returning early to prevent further processing with invalid data.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39850", "url": "https://ubuntu.com/security/CVE-2025-39850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects When the \"proxy\" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the \"any\" remote (0.0.0.0 / ::). The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4]. Fix by checking that the remote destination exists before dereferencing it. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3 [3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77 [4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39851", "url": "https://ubuntu.com/security/CVE-2025-39851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix NPD when refreshing an FDB entry with a nexthop object VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39852", "url": "https://ubuntu.com/security/CVE-2025-39852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6 When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just exits the function. This ends up causing a memory-leak: unreferenced object 0xffff0000281a8200 (size 2496): comm \"softirq\", pid 0, jiffies 4295174684 hex dump (first 32 bytes): 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................ 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............ backtrace (crc 5ebdbe15): kmemleak_alloc+0x44/0xe0 kmem_cache_alloc_noprof+0x248/0x470 sk_prot_alloc+0x48/0x120 sk_clone_lock+0x38/0x3b0 inet_csk_clone_lock+0x34/0x150 tcp_create_openreq_child+0x3c/0x4a8 tcp_v6_syn_recv_sock+0x1c0/0x620 tcp_check_req+0x588/0x790 tcp_v6_rcv+0x5d0/0xc18 ip6_protocol_deliver_rcu+0x2d8/0x4c0 ip6_input_finish+0x74/0x148 ip6_input+0x50/0x118 ip6_sublist_rcv+0x2fc/0x3b0 ipv6_list_rcv+0x114/0x170 __netif_receive_skb_list_core+0x16c/0x200 netif_receive_skb_list_internal+0x1f0/0x2d0 This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need to be called. They make sure the newsk will end up being correctly free'd. tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit label that takes care of things. So, this patch here makes sure tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar error-handling and thus fixes the leak for TCP-AO.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39901", "url": "https://ubuntu.com/security/CVE-2025-39901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: remove read access to debugfs files The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c (\"i40e: debugfs interface\"). Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here. On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be \": \". For 'netdev_ops', this will be \": \". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism. We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc. A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input. Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once. In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39854", "url": "https://ubuntu.com/security/CVE-2025-39854", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the \"low latency\" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same \"ready\" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-38556", "url": "https://ubuntu.com/security/CVE-2025-38556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: Harden s32ton() against conversion to 0 bits Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38502", "url": "https://ubuntu.com/security/CVE-2025-38502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix oob access in cgroup local storage Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf); For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access. To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.", "cve_priority": "medium", "cve_public_date": "2025-08-16 10:15:00 UTC" }, { "cve": "CVE-2025-39843", "url": "https://ubuntu.com/security/CVE-2025-39843", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: slub: avoid wake up kswapd in set_track_prepare set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock. Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since ___slab_alloc() has preemption disabled, we mask out __GFP_DIRECT_RECLAIM from the flags there. The oops looks something like: BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c ___slab_alloc+0xccc __kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ...", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39920", "url": "https://ubuntu.com/security/CVE-2025-39920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pcmcia: Add error handling for add_interval() in do_validate_mem() In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next. This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39902", "url": "https://ubuntu.com/security/CVE-2025-39902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slub: avoid accessing metadata when pointer is invalid in object_err() object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object. One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process. In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39838", "url": "https://ubuntu.com/security/CVE-2025-39838", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: prevent NULL pointer dereference in UTF16 conversion There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash. This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer. Found by Linux Verification Center (linuxtesting.org) with SVACE", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39839", "url": "https://ubuntu.com/security/CVE-2025-39839", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix OOB read/write in network-coding decode batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write. Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39841", "url": "https://ubuntu.com/security/CVE-2025-39841", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix buffer free/clear order in deferred receive path Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39891", "url": "https://ubuntu.com/security/CVE-2025-39891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Initialize the chan_stats array to zero The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey(). There are two potential issues here. What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak. Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc().", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39842", "url": "https://ubuntu.com/security/CVE-2025-39842", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: prevent release journal inode after journal shutdown Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode(). ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> \t jbd2_journal_release_jbd_inode(osb->journal->j_journal, Adding osb->journal checks will prevent null-ptr-deref during the above execution path.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39895", "url": "https://ubuntu.com/security/CVE-2025-39895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched: Fix sched_numa_find_nth_cpu() if mask offline sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer. The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline): [ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000 [ 1.423635] Mem abort info: [ 1.423889] ESR = 0x0000000096000006 [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.424715] SET = 0, FnV = 0 [ 1.424995] EA = 0, S1PTW = 0 [ 1.425279] FSC = 0x06: level 2 translation fault [ 1.425735] Data abort info: [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000 [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000 [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP [ 1.429525] Modules linked in: [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT) [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488 [ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488 [ 1.432543] sp : ffffffc084e1b960 [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0 [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378 [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7 [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372 [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860 [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000 [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68 [ 1.439332] Call trace: [ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P) [ 1.440016] smp_call_function_any+0xc8/0xd0 [ 1.440416] armv8_pmu_init+0x58/0x27c [ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c [ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8 [ 1.441603] armv8_pmu_device_probe+0x1c/0x28 [ 1.442007] platform_probe+0x5c/0xac [ 1.442347] really_probe+0xbc/0x298 [ 1.442683] __driver_probe_device+0x78/0x12c [ 1.443087] driver_probe_device+0xdc/0x160 [ 1.443475] __driver_attach+0x94/0x19c [ 1.443833] bus_for_each_dev+0x74/0xd4 [ 1.444190] driver_attach+0x24/0x30 [ 1.444525] bus_add_driver+0xe4/0x208 [ 1.444874] driver_register+0x60/0x128 [ 1.445233] __platform_driver_register+0x24/0x30 [ 1.445662] armv8_pmu_driver_init+0x28/0x4c [ 1.446059] do_one_initcall+0x44/0x25c [ 1.446416] kernel_init_freeable+0x1dc/0x3bc [ 1.446820] kernel_init+0x20/0x1d8 [ 1.447151] ret_from_fork+0x10/0x20 [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803) [ 1.448040] ---[ end trace 0000000000000000 ]--- [ 1.448483] note: swapper/0[1] exited with preempt_count 1 [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.449741] SMP: stopping secondary CPUs [ 1.450105] Kernel Offset: disabled [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b [ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39844", "url": "https://ubuntu.com/security/CVE-2025-39844", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: move page table sync declarations to linux/pgtable.h During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap); In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 (\"x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes\")) so that all tasks in the system can see the new vmemmap area. However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually. We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates. It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync. # The solution: Make page table sync more code robust and harder to miss To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions. The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables. pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); } It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39845", "url": "https://ubuntu.com/security/CVE-2025-39845", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure page tables are properly synchronized when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It also fixes a crash in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds() [1]: BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmap_set_pmd+0xff/0x230 vmemmap_populate_hugepages+0x176/0x180 vmemmap_populate+0x34/0x80 __populate_section_memmap+0x41/0x90 sparse_add_section+0x121/0x3e0 __add_pages+0xba/0x150 add_pages+0x1d/0x70 memremap_pages+0x3dc/0x810 devm_memremap_pages+0x1c/0x60 xe_devm_add+0x8b/0x100 [xe] xe_tile_init_noalloc+0x6a/0x70 [xe] xe_device_probe+0x48c/0x740 [xe] [... snip ...]", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39846", "url": "https://ubuntu.com/security/CVE-2025-39846", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region() In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource(). Fix this bug by adding a check of res.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39847", "url": "https://ubuntu.com/security/CVE-2025-39847", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix memory leak in pad_compress_skb If alloc_skb() fails in pad_compress_skb(), it returns NULL without releasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop; drop: kfree_skb(skb); When pad_compress_skb() returns NULL, the reference to the old skb is lost and kfree_skb(skb) ends up doing nothing, leading to a memory leak. Align pad_compress_skb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the new_skb variable so the original skb is not lost when pad_compress_skb() fails.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39848", "url": "https://ubuntu.com/security/CVE-2025-39848", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ax25: properly unshare skbs in ax25_kiss_rcv() Bernard Pidoux reported a regression apparently caused by commit c353e8983e0d (\"net: introduce per netns packet chains\"). skb->dev becomes NULL and we crash in __netif_receive_skb_core(). Before above commit, different kind of bugs or corruptions could happen without a major crash. But the root cause is that ax25_kiss_rcv() can queue/mangle input skb without checking if this skb is shared or not. Many thanks to Bernard Pidoux for his help, diagnosis and tests. We had a similar issue years ago fixed with commit 7aaed57c5c28 (\"phonet: properly unshare skbs in phonet_rcv()\").", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39849", "url": "https://ubuntu.com/security/CVE-2025-39849", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39853", "url": "https://ubuntu.com/security/CVE-2025-39853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix potential invalid access when MAC list is empty list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced. Fix this by using list_first_entry_or_null instead of list_first_entry.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39857", "url": "https://ubuntu.com/security/CVE-2025-39857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync() BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc] ... Call Trace: smcr_buf_map_link+0x211/0x2a0 [smc] __smc_buf_create+0x522/0x970 [smc] smc_buf_create+0x3a/0x110 [smc] smc_find_rdma_v2_device_serv+0x18f/0x240 [smc] ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc] smc_listen_find_device+0x1dd/0x2b0 [smc] smc_listen_work+0x30f/0x580 [smc] process_one_work+0x18c/0x340 worker_thread+0x242/0x360 kthread+0xe7/0x220 ret_from_fork+0x13a/0x160 ret_from_fork_asm+0x1a/0x30 If the software RoCE device is used, ibdev->dma_device is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39860", "url": "https://ubuntu.com/security/CVE-2025-39860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() syzbot reported the splat below without a repro. In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that. The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit. bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release(). Two threads could see the same socket during the list iteration in bt_accept_dequeue(): CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF Depending on the timing, the other thread could show up in the \"Freed by task\" part. Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release(). [0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39861", "url": "https://ubuntu.com/security/CVE-2025-39861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: vhci: Prevent use-after-free by removing debugfs files early Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed. Previously, debugfs files such as \"force_suspend\", \"force_wakeup\", and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors. Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39894", "url": "https://ubuntu.com/security/CVE-2025-39894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm When send a broadcast packet to a tap device, which was added to a bridge, br_nf_local_in() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:br_nf_local_in+0x168/0x200 Call Trace: nf_hook_slow+0x3e/0xf0 br_pass_frame_up+0x103/0x180 br_handle_frame_finish+0x2de/0x5b0 br_nf_hook_thresh+0xc0/0x120 br_nf_pre_routing_finish+0x168/0x3a0 br_nf_pre_routing+0x237/0x5e0 br_handle_frame+0x1ec/0x3c0 __netif_receive_skb_core+0x225/0x1210 __netif_receive_skb_one_core+0x37/0xa0 netif_receive_skb+0x36/0x160 tun_get_user+0xa54/0x10c0 tun_chr_write_iter+0x65/0xb0 vfs_write+0x305/0x410 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f ---[ end trace 0000000000000000 ]--- To solve the hash conflict, nf_ct_resolve_clash() try to merge the conntracks, and update skb->_nfct. However, br_nf_local_in() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning. If confirm() does not insert the conntrack entry and return NF_DROP, the warning may also occur. There is no need to reserve the WARN_ON_ONCE, just remove it.", "cve_priority": "medium", "cve_public_date": "2025-10-01 08:15:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39864", "url": "https://ubuntu.com/security/CVE-2025-39864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix use-after-free in cmp_bss() Following bss_free() quirk introduced in commit 776b3580178f (\"cfg80211: track hidden SSID networks properly\"), adjust cfg80211_update_known_bss() to free the last beacon frame elements only if they're not shared via the corresponding 'hidden_beacon_bss' pointer.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39865", "url": "https://ubuntu.com/security/CVE-2025-39865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: fix NULL pointer dereference in tee_shm_put tee_shm_put have NULL pointer dereference: __optee_disable_shm_cache --> \tshm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> \t\ttee_shm_put(shm);//crash Add check in tee_shm_put to fix it. panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39866", "url": "https://ubuntu.com/security/CVE-2025-39866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix use-after-free in __mark_inode_dirty() An use-after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching. CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1 ...... pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mark_inode_dirty+0x124/0x418 lr : __mark_inode_dirty+0x118/0x418 sp : ffffffc08c9dbbc0 ........ Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198 Root cause is: systemd-random-seed kworker ---------------------------------------------------------------------- ___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issue Fix this race condition by holding inode spinlock until wb_wakeup_delayed() finished.", "cve_priority": "medium", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2025-39811", "url": "https://ubuntu.com/security/CVE-2025-39811", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Clear the scratch_pt pointer on error Avoid triggering a dereference of an error pointer on cleanup in xe_vm_free_scratch() by clearing any scratch_pt error pointer. (cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8)", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39815", "url": "https://ubuntu.com/security/CVE-2025-39815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: fix stack overrun when loading vlenb The userspace load can put up to 2048 bits into an xlen bit stack buffer. We want only xlen bits, so check the size beforehand.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39810", "url": "https://ubuntu.com/security/CVE-2025-39810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix memory corruption when FW resources change during ifdown bnxt_set_dflt_rings() assumes that it is always called before any TC has been created. So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1. In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations(). This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1. This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings(). Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above. Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39836", "url": "https://ubuntu.com/security/CVE-2025-39836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efi: stmm: Fix incorrect buffer allocation method The communication buffer allocated by setup_mm_hdr() is later on passed to tee_shm_register_kernel_buf(). The latter expects those buffers to be contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause various corruptions or BUGs, specifically since commit 9aec2fb0fd5e (\"slab: allocate frozen pages\"), though it was broken before as well. Fix this by using alloc_pages_exact() instead of kmalloc().", "cve_priority": "medium", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39805", "url": "https://ubuntu.com/security/CVE-2025-39805", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: fix unregister_netdev call order in macb_remove() When removing a macb device, the driver calls phy_exit() before unregister_netdev(). This leads to a WARN from kernfs: ------------[ cut here ]------------ kernfs: can not remove 'attached_dev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfs_remove_by_name_ns+0xd8/0xf0 sysfs_remove_link+0x24/0x58 phy_detach+0x5c/0x168 phy_disconnect+0x4c/0x70 phylink_disconnect_phy+0x6c/0xc0 [phylink] macb_close+0x6c/0x170 [macb] ... macb_remove+0x60/0x168 [macb] platform_remove+0x5c/0x80 ... The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus. Fix this by moving unregister_netdev() ahead of phy_exit() in macb_remove().", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39829", "url": "https://ubuntu.com/security/CVE-2025-39829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: trace/fgraph: Fix the warning caused by missing unregister notifier This warning was triggered during testing on v6.16: notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written. Fixed by adding unregister_pm_notifier in the exception path.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39835", "url": "https://ubuntu.com/security/CVE-2025-39835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: do not propagate ENODATA disk errors into xattr code ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found. However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as \"attribute not found\" when in fact it's an IO (disk) error. At worst, we may oops in xfs_attr_leaf_get() when we do: \terror = xfs_attr_leaf_hasname(args, &bp); \tif (error == -ENOATTR) { \t\txfs_trans_brelse(args->trans, bp); \t\treturn error; \t} because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfs_trans_brelse will then null-deref it. As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don't let unique errors like this leak up into higher xfs functions - many like this should be remapped to EIO. However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later. (Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.)", "cve_priority": "low", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39819", "url": "https://ubuntu.com/security/CVE-2025-39819", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/smb: Fix inconsistent refcnt update A possible inconsistent update of refcount was identified in `smb2_compound_op`. Such inconsistent update could lead to possible resource leaks. Why it is a possible bug: 1. In the comment section of the function, it clearly states that the reference to `cfile` should be dropped after calling this function. 2. Every control flow path would check and drop the reference to `cfile`, except the patched one. 3. Existing callers would not handle refcount update of `cfile` if -ENOMEM is returned. To fix the bug, an extra goto label \"out\" is added, to make sure that the cleanup logic would always be respected. As the problem is caused by the allocation failure of `vars`, the cleanup logic between label \"finished\" and \"out\" can be safely ignored. According to the definition of function `is_replayable_error`, the error code of \"-ENOMEM\" is not recoverable. Therefore, the replay logic also gets ignored.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39808", "url": "https://ubuntu.com/security/CVE-2025-39808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version() in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58) add null check logic to ntrig_report_version() before calling hid_to_usb_dev()", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39806", "url": "https://ubuntu.com/security/CVE-2025-39806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it. Below is the KASAN splat after the out of bounds access happens: [ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 [...]", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39824", "url": "https://ubuntu.com/security/CVE-2025-39824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix UAF via HID_CLAIMED_INPUT validation After hid_hw_start() is called hidinput_connect() will eventually be called to set up the device with the input layer since the HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect() all input and output reports are processed and corresponding hid_inputs are allocated and configured via hidinput_configure_usages(). This process involves slot tagging report fields and configuring usages by setting relevant bits in the capability bitmaps. However it is possible that the capability bitmaps are not set at all leading to the subsequent hidinput_has_been_populated() check to fail leading to the freeing of the hid_input and the underlying input device. This becomes problematic because a malicious HID device like a ASUS ROG N-Key keyboard can trigger the above scenario via a specially crafted descriptor which then leads to a user-after-free when the name of the freed input device is written to later on after hid_hw_start(). Below, report 93 intentionally utilises the HID_UP_UNDEFINED Usage Page which is skipped during usage configuration, leading to the frees. 0x05, 0x0D, // Usage Page (Digitizer) 0x09, 0x05, // Usage (Touch Pad) 0xA1, 0x01, // Collection (Application) 0x85, 0x0D, // Report ID (13) 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) 0x09, 0xC5, // Usage (0xC5) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x04, // Report Count (4) 0xB1, 0x02, // Feature (Data,Var,Abs) 0x85, 0x5D, // Report ID (93) 0x06, 0x00, 0x00, // Usage Page (Undefined) 0x09, 0x01, // Usage (0x01) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xFF, 0x00, // Logical Maximum (255) 0x75, 0x08, // Report Size (8) 0x95, 0x1B, // Report Count (27) 0x81, 0x02, // Input (Data,Var,Abs) 0xC0, // End Collection Below is the KASAN splat after triggering the UAF: [ 21.672709] ================================================================== [ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80 [ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54 [ 21.673700] [ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary) [ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 21.673700] Call Trace: [ 21.673700] [ 21.673700] dump_stack_lvl+0x5f/0x80 [ 21.673700] print_report+0xd1/0x660 [ 21.673700] kasan_report+0xe5/0x120 [ 21.673700] __asan_report_store8_noabort+0x1b/0x30 [ 21.673700] asus_probe+0xeeb/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 [...] [ 21.673700] [ 21.673700] Allocated by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_alloc_info+0x3b/0x50 [ 21.673700] __kasan_kmalloc+0x9c/0xa0 [ 21.673700] __kmalloc_cache_noprof+0x139/0x340 [ 21.673700] input_allocate_device+0x44/0x370 [ 21.673700] hidinput_connect+0xcb6/0x2630 [ 21.673700] hid_connect+0xf74/0x1d60 [ 21.673700] hid_hw_start+0x8c/0x110 [ 21.673700] asus_probe+0x5a3/0xf80 [ 21.673700] hid_device_probe+0x2ee/0x700 [ 21.673700] really_probe+0x1c6/0x6b0 [ 21.673700] __driver_probe_device+0x24f/0x310 [ 21.673700] driver_probe_device+0x4e/0x220 [...] [ 21.673700] [ 21.673700] Freed by task 54: [ 21.673700] kasan_save_stack+0x3d/0x60 [ 21.673700] kasan_save_track+0x18/0x40 [ 21.673700] kasan_save_free_info+0x3f/0x60 [ 21.673700] __kasan_slab_free+0x3c/0x50 [ 21.673700] kfre ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39823", "url": "https://ubuntu.com/security/CVE-2025-39823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: use array_index_nospec with indices that come from guest min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39817", "url": "https://ubuntu.com/security/CVE-2025-39817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare Observed on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0 If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can become negative, leadings to oob. The issue can be triggered by parallel lookups using invalid filename: T1\t\t\tT2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list \t\t\tlookup_open \t\t\t d_alloc_parallel \t\t\t __d_lookup_rcu \t\t\t __d_lookup_rcu_op_compare \t\t\t hlist_bl_for_each_entry_rcu \t\t\t // invalid dentry can be retrieved \t\t\t ->d_compare \t\t\t efivarfs_d_compare \t\t\t // oob Fix it by checking 'guid' before cmp.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39812", "url": "https://ubuntu.com/security/CVE-2025-39812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: initialize more fields in sctp_v6_from_sk() syzbot found that sin6_scope_id was not properly initialized, leading to undefined behavior. Clear sin6_scope_id and sin6_flowinfo. BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-39827", "url": "https://ubuntu.com/security/CVE-2025-39827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: include node references in rose_neigh refcount Current implementation maintains two separate reference counting mechanisms: the 'count' field in struct rose_neigh tracks references from rose_node structures, while the 'use' field (now refcount_t) tracks references from rose_sock. This patch merges these two reference counting systems using 'use' field for proper reference management. Specifically, this patch adds incrementing and decrementing of rose_neigh->use when rose_neigh->count is incremented or decremented. This patch also modifies rose_rt_free(), rose_rt_device_down() and rose_clear_route() to properly release references to rose_neigh objects before freeing a rose_node through rose_remove_node(). These changes ensure rose_neigh structures are properly freed only when all references, including those from rose_node structures, are released. As a result, this resolves a slab-use-after-free issue reported by Syzbot.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39826", "url": "https://ubuntu.com/security/CVE-2025-39826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rose: convert 'use' field to refcount_t The 'use' field in struct rose_neigh is used as a reference counter but lacks atomicity. This can lead to race conditions where a rose_neigh structure is freed while still being referenced by other code paths. For example, when rose_neigh->use becomes zero during an ioctl operation via rose_rt_ioctl(), the structure may be removed while its timer is still active, potentially causing use-after-free issues. This patch changes the type of 'use' from unsigned short to refcount_t and updates all code paths to use rose_neigh_hold() and rose_neigh_put() which operate reference counts atomically.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39832", "url": "https://ubuntu.com/security/CVE-2025-39832", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix lockdep assertion on sync reset unload event Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning. Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2025-09-16 14:15:00 UTC" }, { "cve": "CVE-2025-39828", "url": "https://ubuntu.com/security/CVE-2025-39828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control(). syzbot reported the splat below. [0] When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message. The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc. The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer. struct atmtcp_control { \tstruct atmtcp_hdr hdr;\t/* must be first */ ... \tatm_kptr_t vcc;\t\t/* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t; The special message is processed in atmtcp_recv_control() called from atmtcp_c_send(). atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control. Let's add a new ->pre_send() hook to validate messages from sendmsg(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 Modules linked in:", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39697", "url": "https://ubuntu.com/security/CVE-2025-39697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().", "cve_priority": "medium", "cve_public_date": "2025-09-05 18:15:00 UTC" }, { "cve": "CVE-2025-39825", "url": "https://ubuntu.com/security/CVE-2025-39825", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix race with concurrent opens in rename(2) Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file. Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:16:00 UTC" }, { "cve": "CVE-2025-39813", "url": "https://ubuntu.com/security/CVE-2025-39813", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix potential warning in trace_printk_seq during ftrace_dump When calling ftrace_dump_one() concurrently with reading trace_pipe, a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race condition. The issue occurs because: CPU0 (ftrace_dump) CPU1 (reader) echo z > /proc/sysrq-trigger !trace_empty(&iter) trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipe trace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULL trace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size) In the context between trace_empty() and trace_find_next_entry_inc() during ftrace_dump, the ring buffer data was consumed by other readers. This caused trace_find_next_entry_inc to return NULL, failing to populate `iter.seq`. At this point, due to the prior trace_iterator_reset, both `iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal, the WARN_ON_ONCE condition is triggered. Move the trace_printk_seq() into the if block that checks to make sure the return value of trace_find_next_entry_inc() is non-NULL in ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before subsequent operations.", "cve_priority": "medium", "cve_public_date": "2025-09-16 13:15:00 UTC" }, { "cve": "CVE-2025-37899", "url": "https://ubuntu.com/security/CVE-2025-37899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in session logoff The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2_sess_setup function which makes use of sess->user.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2025-22037", "url": "https://ubuntu.com/security/CVE-2025-22037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference in alloc_preauth_hash() The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauth_info is not allocated. This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-103.103 -proposed tracker (LP: #2141411)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", "", " * xhci_find_slot_id_by_port kernel panic on boot on arm64 (LP: #2141314)", " - Revert \"xhci: fix stale flag preventig URBs after link state error is", " cleared\"", "", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", "", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - thunderbolt: Show path name in debug log when path is deactivated", " - thunderbolt: Log path activation failures without WARN backtraces", "", " * x86: tsc: Fix TSC clock source being disabled when SNC is enabled causing", " fall back to less precise HPET (LP: #2138120)", " - x86/tsc: Use topology_max_packages() to get package number", "", " * Random flickering with Intel i915 (CoffeeLake and WhiskeyLake) on Linux", " 6.8 (LP: #2136958)", " - SAUCE: iommu/intel: disable DMAR for CFL and WHL integrated gfx", "", " * CXL: Fix slab-out-of-bounds in cxl_setup_parent_dport (LP: #2130240)", " - cxl/pci: Get AER capability address from RCRB only for RCH dport", " - cxl/test: Skip cxl_setup_parent_dport() for emulated dports", "", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633)", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: lan966x: Fix the initialization of taprio", " - net/mlx5e: Fix validation logic in rate limiting", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - net: dsa: sja1105: simplify static configuration reload", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: pcc: Refactor error handling in irq handler into separate", " function", " - mailbox: pcc: don't zero error register", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-mem: Allow specifying the byte order in Octal DTR mode", " - spi: spi-mem: Extend spi-mem operations with a per-operation maximum", " frequency", " - spi: spi-mem: Add a new controller capability", " - spi: nxp-fspi: Support per spi-mem operation frequency switches", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - mptcp: clear scheduled subflows on retransmit", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - nfsd: Replace clamp_t in nfsd4_get_drc_mem()", " - usb: udc: Add trace event for usb_gadget_set_state", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - can: rcar_canfd: Fix CAN-FD mode as default", " - iio: adc: rtq6056: Correct the sign bit index", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - drm/amd/display: Don't change brightness for disabled connectors", " - KVM: SVM: Introduce svm_recalc_lbr_msr_intercepts()", " - KVM: nSVM: Always recalculate LBR MSR intercepts in svm_update_lbrv()", " - KVM: nSVM: Fix and simplify LBR virtualization handling with nested", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - wifi: ath12k: correctly handle mcast packets for clients", " - drm/i915/dp: Initialize the source OUI write timestamp always", " - SAUCE: bpf: introduce __MAX_BPF_PROG_TYPE delimiter", " - Upstream stable to v6.6.119, v6.12.61", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", "", " * Noble update: upstream stable patchset 2026-02-03 (LP: #2139633) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624)", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - smb: client: introduce close_cached_dir_locked()", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix premature close in case of fallback", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - bcma: don't register devices disabled in OF", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: net: use BASH for bareudp testing", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - f2fs: compress: change the first parameter of page_array_{alloc,free} to", " sbi", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - uio_hv_generic: Set event for all channels on the device", " - maple_tree: fix tracepoint string pointers", " - selftests: mptcp: join: endpoints: longer transfer", " - HID: amd_sfh: Stop sensor before starting", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - mptcp: fix duplicate reset on fastclose", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - xfrm: set err and extack on failure to create pcpu SA", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - selftests: net: lib: Do not overwrite error messages", " - af_unix: Cache state->msg in unix_stream_read_generic().", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: tls: Change async resync helpers argument", " - ALSA: usb-audio: Fix missing unlock at error path of maxpacksize check", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - tty/vt: fix up incorrect backport to stable releases", " - Upstream stable to v6.6.118, v6.12.60", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68198", " - crash: fix crashkernel resource shrink", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-38627", " - f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-02-02 (LP: #2139624) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460)", " - net: usb: asix_devices: Check return value of usbnet_get_endpoints", " - fbdev: atyfb: Check if pll_ops->init_pll failed", " - ACPI: button: Call input_free_device() on failing input device", " registration", " - Bluetooth: rfcomm: fix modem control handling", " - fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS", " - fbdev: valkyriefb: Fix reference count leak in valkyriefb_init", " - mptcp: drop bogus optimization in __mptcp_check_push()", " - mptcp: restore window probe", " - ASoC: qdsp6: q6asm: do not sleep while atomic", " - wifi: ath10k: Fix memory leak on unsupported WMI command", " - wifi: ath11k: Add missing platform IDs for quirk table", " - wifi: ath12k: free skb during idr cleanup callback", " - drm/msm/a6xx: Fix GMU firmware parser", " - ALSA: usb-audio: fix control pipe direction", " - scsi: ufs: core: Initialize value of an attribute returned by uic cmd", " - ASoC: Intel: avs: Unprepare a stream when XRUN occurs", " - ASoC: fsl_sai: fix bit order for DSD format", " - libbpf: Fix powerpc's stack register definition in bpf_tracing.h", " - Bluetooth: btmtksdio: Add pmctrl handling for BT closed state during", " reset", " - Bluetooth: HCI: Fix tracking of advertisement set/instance 0x00", " - Bluetooth: ISO: Fix another instance of dst_type handling", " - Bluetooth: hci_core: Fix tracking of periodic advertisement", " - drm/etnaviv: fix flush sequence logic", " - net: hns3: return error code when function fails", " - sfc: fix potential memory leak in efx_mae_process_mport()", " - drm/amd/pm: fix smu table id bound check issue in smu_cmn_update_table()", " - drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji", " - drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Iceland", " - block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL", " - block: make REQ_OP_ZONE_OPEN a write operation", " - drm/mediatek: Fix device use-after-free on unbind", " - mptcp: fix MSG_PEEK stream corruption", " - cpuidle: governors: menu: Rearrange main loop in menu_select()", " - cpuidle: governors: menu: Select polling state in some more cases", " - net: phy: dp83867: Disable EEE support as not implemented", " - [Config] disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP for s390x", " - drm/sched: Fix race in drm_sched_entity_select_rq()", " - soc: aspeed: socinfo: Add AST27xx silicon IDs", " - soc: qcom: smem: Fix endian-unaware access of num_entries", " - spi: loopback-test: Don't use %pK through printk", " - bpf: Don't use %pK through printk", " - pinctrl: single: fix bias pull up/down handling in pin_config_set", " - mmc: host: renesas_sdhi: Fix the actual clock", " - memstick: Add timeout to prevent indefinite waiting", " - irqchip/sifive-plic: Respect mask state when setting affinity", " - selftests/bpf: Fix bpf_prog_detach2 usage in test_lirc_mode2", " - arc: Fix __fls() const-foldability via __builtin_clzl()", " - selftests/bpf: Upon failures, exit with code 1 in test_xsk.sh", " - irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment", " - ACPI: PRM: Skip handlers with NULL handler_address or NULL VA", " - ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids[]", " - power: supply: qcom_battmgr: add OOI chemistry", " - hwmon: (k10temp) Add device ID for Strix Halo", " - hwmon: (sbtsi_temp) AMD CPU extended temperature range support", " - pinctrl: keembay: release allocated memory in detach path", " - power: supply: sbs-charger: Support multiple devices", " - hwmon: sy7636a: add alias", " - irqchip/loongson-pch-lpc: Use legacy domain for PCH-LPC IRQ controller", " - arm64: zynqmp: Revert usb node drive strength and slew rate for zcu106", " - soc/tegra: fuse: Add Tegra114 nvmem cells and fuse lookups", " - ARM: tegra: transformer-20: add missing magnetometer interrupt", " - ARM: tegra: transformer-20: fix audio-codec interrupt", " - mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card", " - ACPICA: dispatcher: Use acpi_ds_clear_operands() in", " acpi_ds_call_control_method()", " - tee: allow a driver to allocate a tee_device without a pool", " - bpf: Do not limit bpf_cgroup_from_id to current's namespace", " - video: backlight: lp855x_bl: Set correct EPROM start for LP8556", " - tools/cpupower: fix error return value in cpupower_write_sysfs()", " - pmdomain: apple: Add \"apple,t8103-pmgr-pwrstate\"", " - power: supply: qcom_battmgr: handle charging state change notifications", " - bpftool: Fix -Wuninitialized-const-pointer warnings with clang >= 21", " - cpuidle: Fail cpuidle device registration if there is one already", " - spi: rpc-if: Add resume support for RZ/G3E", " - clocksource/drivers/vf-pit: Replace raw_readl/writel to readl/writel", " - riscv: bpf: Fix uninitialized symbol 'retval_off'", " - bpf: Clear pfmemalloc flag when freeing all fragments", " - nvme: Use non zero KATO for persistent discovery connections", " - uprobe: Do not emulate/sstep original instruction when ip is changed", " - hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex", " - hwmon: (dell-smm) Add support for Dell OptiPlex 7040", " - tools/cpupower: Fix incorrect size in cpuidle_state_disable()", " - tools/power x86_energy_perf_policy: Fix incorrect fopen mode usage", " - tools/power x86_energy_perf_policy: Enhance HWP enable", " - tools/power x86_energy_perf_policy: Prefer driver HWP limits", " - mfd: stmpe: Remove IRQ domain upon removal", " - mfd: stmpe-i2c: Add missing MODULE_LICENSE", " - mfd: madera: Work around false-positive -Wininitialized warning", " - mfd: da9063: Split chip variant reading in two bus transactions", " - drm/amd/display: ensure committing streams is seamless", " - drm/amd/display: Increase AUX Intra-Hop Done Max Wait Duration", " - drm/amd/display: add more cyan skillfish devices", " - drm/amd/display: update dpp/disp clock from smu clock table", " - drm/amd/pm: Use cached metrics data on aldebaran", " - drm/amd/pm: Use cached metrics data on arcturus", " - drm/amdgpu/jpeg: Hold pg_lock before jpeg poweroff", " - drm/nouveau: replace snprintf() with scnprintf() in nvkm_snprintbf()", " - PCI: Disable MSI on RDC PCI to PCIe bridges", " - selftests/net: Replace non-standard __WORDSIZE with sizeof(long) * 8", " - selftests/net: Ensure assert() triggers in psock_tpacket.c", " - wifi: rtw88: sdio: use indirect IO for device registers before power-on", " - drm/amdkfd: return -ENOTTY for unsupported IOCTLs", " - media: pci: ivtv: Don't create fake v4l2_fh", " - media: amphion: Delete v4l2_fh synchronously in .release()", " - drm/tidss: Use the crtc_* timings when programming the HW", " - drm/bridge: cdns-dsi: Fix REG_WAKEUP_TIME value", " - drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST", " - drm/tidss: Set crtc modesetting parameters with adjusted mode", " - media: i2c: Kconfig: Ensure a dependency on HAVE_CLK for", " VIDEO_CAMERA_SENSOR", " - x86/vsyscall: Do not require X86_PF_INSTR to emulate vsyscall", " - net: stmmac: Check stmmac_hw_setup() in stmmac_resume()", " - ice: Don't use %pK through printk or tracepoints", " - thunderbolt: Use is_pciehp instead of is_hotplug_bridge", " - powerpc/eeh: Use result of error_detected() in uevent", " - s390/pci: Use pci_uevent_ers() in PCI recovery", " - bridge: Redirect to backup port when port is administratively down", " - scsi: ufs: host: mediatek: Fix auto-hibern8 timer configuration", " - scsi: ufs: host: mediatek: Assign power mode userdata before FASTAUTO", " mode change", " - scsi: ufs: host: mediatek: Change reset sequence for improved stability", " - scsi: ufs: host: mediatek: Fix invalid access in vccqx handling", " - drm/bridge: display-connector: don't set OP_DETECT for DisplayPorts", " - drm/amdkfd: Handle lack of READ permissions in SVM mapping", " - iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg sample before", " setting register", " - iio: adc: imx93_adc: load calibrated values even calibration failed", " - usb: gadget: f_ncm: Fix MAC assignment NCM ethernet", " - char: misc: Make misc_register() reentry for miscdevice who wants", " dynamic minor", " - char: misc: Does not request module for miscdevice with dynamic minor", " - net: When removing nexthops, don't call synchronize_net if it is not", " necessary", " - net: Call trace_sock_exceed_buf_limit() for memcg failure with", " SK_MEM_RECV.", " - PCI/P2PDMA: Fix incorrect pointer usage in devm_kfree() call", " - ALSA: usb-audio: Add validation of UAC2/UAC3 effect units", " - rds: Fix endianness annotation for RDS_MPATH_HASH", " - scsi: mpi3mr: Fix controller init failure on fault during queue creation", " - scsi: pm80xx: Fix race condition caused by static variables", " - extcon: adc-jack: Fix wakeup source leaks on device unbind", " - remoteproc: wkup_m3: Use devm_pm_runtime_enable() helper", " - net: phy: fixed_phy: let fixed_phy_unregister free the phy_device", " - fuse: zero initialize inode private data", " - drm/amdkfd: fix vram allocation failure for a special case", " - drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption", " - media: fix uninitialized symbol warnings", " - drm/amdgpu: Respect max pixel clock for HDMI and DVI-D (v2)", " - mips: lantiq: danube: add missing properties to cpu node", " - mips: lantiq: danube: add model to EASY50712 dts", " - mips: lantiq: danube: add missing device_type in pci node", " - mips: lantiq: xway: sysctrl: rename stp clock", " - mips: lantiq: danube: rename stp node on EASY50712 reference board", " - crypto: qat - use kcalloc() in qat_uclo_map_objs_from_mof()", " - scsi: pm8001: Use int instead of u32 to store error codes", " - ptp: Limit time setting of PTP clocks", " - dmaengine: sh: setup_xref error handling", " - dmaengine: mv_xor: match alloc_wc and free_wc", " - dmaengine: dw-edma: Set status for callback_result", " - drm/msm/dsi/phy: Toggle back buffer resync after preparing PLL", " - drm/msm/dsi/phy_7nm: Fix missing initial VCO rate", " - drm/amdgpu: Allow kfd CRIU with no buffer objects", " - ipv6: Add sanity checks on ipv6_devconf.rpl_seg_enabled", " - net: nfc: nci: Increase NCI_DATA_TIMEOUT to 3000 ms", " - media: adv7180: Add missing lock in suspend callback", " - media: adv7180: Do not write format to device in set_fmt", " - media: adv7180: Only validate format in querystd", " - media: verisilicon: Explicitly disable selection api ioctls for decoders", " - ALSA: usb-audio: apply quirk for MOONDROP Quark2", " - net: call cond_resched() less often in __release_sock()", " - smsc911x: add second read of EEPROM mac when possible corruption seen", " - iommu/apple-dart: Clear stream error indicator bits for T8110 DARTs", " - drm/amd: add more cyan skillfish PCI ids", " - drm/amdgpu: don't enable SMU on cyan skillfish", " - drm/amdgpu: add support for cyan skillfish gpu_info", " - usb: gadget: f_hid: Fix zero length packet transfer", " - drm/msm: make sure to not queue up recovery more than once", " - char: Use list_del_init() in misc_deregister() to reinitialize list", " pointer", " - media: ov08x40: Fix the horizontal flip control", " - media: i2c: og01a1b: Specify monochrome media bus format instead of", " Bayer", " - scsi: ufs: host: mediatek: Enhance recovery on resume failure", " - scsi: ufs: host: mediatek: Enhance recovery on hibernation exit failure", " - net: phy: marvell: Fix 88e1510 downshift counter errata", " - scsi: ufs: host: mediatek: Disable auto-hibern8 during power mode", " changes", " - wifi: mac80211: Fix HE capabilities element check", " - phy: cadence: cdns-dphy: Enable lower resolutions in dphy", " - phy: renesas: r8a779f0-ether-serdes: add new step added to latest", " datasheet", " - phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf register 0", " - net: sh_eth: Disable WoL if system can not suspend", " - selftests: net: replace sleeps in fcnal-test with waits", " - media: redrat3: use int type to store negative error codes", " - selftests: traceroute: Use require_command()", " - netfilter: nf_reject: don't reply to icmp error messages", " - x86/kvm: Prefer native qspinlock for dedicated vCPUs irrespective of", " PV_UNHALT", " - selftests: Disable dad for ipv6 in fcnal-test.sh", " - eth: 8139too: Make 8139TOO_PIO depend on !NO_IOPORT_MAP", " - [Config] disable 8139TOO_PIO for armhf", " - selftests: Replace sleep with slowwait", " - HID: asus: add Z13 folio to generic group for multitouch to work", " - watchdog: s3c2410_wdt: Fix max_timeout being calculated larger", " - crypto: sun8i-ce - remove channel timeout field", " - PCI: dwc: Verify the single eDMA IRQ in dw_pcie_edma_irq_verify()", " - crypto: caam - double the entropy delay interval for retry", " - net/cls_cgroup: Fix task_get_classid() during qdisc run", " - wifi: mt76: mt7921: Add 160MHz beamformee capability for mt7922 device", " - wifi: mt76: mt7996: Temporarily disable EPCS", " - ALSA: serial-generic: remove shared static buffer", " - drm/amdgpu: Use memdup_array_user in amdgpu_cs_wait_fences_ioctl", " - drm/amd: Avoid evicting resources at S5", " - drm/amd/display: Fix DVI-D/HDMI adapters", " - drm/amd/display: Disable VRR on DCE 6", " - ethernet: Extend device_get_mac_address() to use NVMEM", " - HID: i2c-hid: Resolve touchpad issues on Dell systems during S4", " - drm/amdgpu: reject gang submissions under SRIOV", " - selftests/Makefile: include $(INSTALL_DEP_TARGETS) in clean target to", " clean net/lib dependency", " - scsi: ufs: core: Disable timestamp functionality if not supported", " - scsi: lpfc: Check return status of lpfc_reset_flush_io_context during", " TGT_RESET", " - scsi: lpfc: Remove ndlp kref decrement clause for F_Port_Ctrl in", " lpfc_cleanup", " - scsi: lpfc: Define size of debugfs entry for xri rebalancing", " - allow finish_no_open(file, ERR_PTR(-E...))", " - usb: mon: Increase BUFF_MAX to 64 MiB to support multi-MB URBs", " - usb: xhci: plat: Facilitate using autosuspend for xhci plat devices", " - ipv6: np->rxpmtu race annotation", " - ASoC: qcom: sc8280xp: explicitly set S16LE format in", " sc8280xp_be_hw_params_fixup()", " - net: phy: clear link parameters on admin link down", " - net: ethernet: microchip: sparx5: make it selectable for ARCH_LAN969X", " - iommu/vt-d: Replace snprintf with scnprintf in dmar_latency_snapshot()", " - wifi: ath10k: Fix connection after GTK rekeying", " - net: intel: fm10k: Fix parameter idx set but not used", " - sparc/module: Add R_SPARC_UA64 relocation handling", " - sparc64: fix prototypes of reads[bwl]()", " - vfio: return -ENOTTY for unsupported device feature", " - PCI/PM: Skip resuming to D0 if device is disconnected", " - remoteproc: qcom: q6v5: Avoid handling handover twice", " - wifi: ath12k: Increase DP_REO_CMD_RING_SIZE to 256", " - drm/amd/display: Add AVI infoframe copy in copy_stream_update_to_stream", " - NFSv4: handle ERR_GRACE on delegation recalls", " - NFSv4.1: fix mount hang after CREATE_SESSION failure", " - net: bridge: Install FDB for bridge MAC on VLAN 0", " - scsi: libfc: Fix potential buffer overflow in fc_ct_ms_fill()", " - accel/habanalabs/gaudi2: fix BMON disable configuration", " - scsi: mpt3sas: Add support for 22.5 Gbps SAS link rate", " - accel/habanalabs: return ENOMEM if less than requested pages were pinned", " - accel/habanalabs/gaudi2: read preboot status after recovering from dirty", " state", " - fs: ext4: change GFP_KERNEL to GFP_NOFS to avoid deadlock", " - ext4: increase IO priority of fastcommit", " - ASoC: stm32: sai: manage context in set_sysclk callback", " - ASoC: tlv320aic3x: Fix class-D initialization for tlv320aic3007", " - net/mlx5e: Don't query FEC statistics when FEC is disabled", " - net: macb: avoid dealing with endianness in macb_set_hwaddr()", " - Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI", " frames", " - ALSA: usb-audio: add mono main switch to Presonus S1824c", " - exfat: limit log print for IO error", " - 6pack: drop redundant locking and refcounting", " - page_pool: Clamp pool size to max 16K pages", " - ksmbd: use sock_create_kern interface to create kernel socket", " - smb: client: transport: avoid reconnects triggered by pending task work", " - char: misc: restrict the dynamic range to exclude reserved minors", " - ACPICA: Update dsmethod.c to get rid of unused variable warning", " - RDMA/irdma: Fix SD index calculation", " - RDMA/irdma: Remove unused struct irdma_cq fields", " - RDMA/irdma: Set irdma_cq cq_num field during CQ create", " - RDMA/hns: Fix the modification of max_send_sge", " - RDMA/hns: Fix wrong WQE data when QP wraps around", " - btrfs: mark dirty extent range for out of bound prealloc extents", " - fs/hpfs: Fix error code for new_inode() failure in", " mkdir/create/mknod/symlink", " - um: Fix help message for ssl-non-raw", " - clk: sunxi-ng: sun6i-rtc: Add A523 specifics", " - rtc: pcf2127: clear minute/second interrupt", " - ARM: at91: pm: save and restore ACR during PLL disable/enable", " - clk: at91: clk-master: Add check for divide by 3", " - clk: at91: clk-sam9x60-pll: force write to PLL_UPDT register", " - clk: ti: am33xx: keep WKUP_DEBUGSS_CLKCTRL enabled", " - NTB: epf: Allow arbitrary BAR mapping", " - 9p: fix /sys/fs/9p/caches overwriting itself", " - cpufreq: tegra186: Initialize all cores to max frequencies", " - 9p: sysfs_init: don't hardcode error to ENOMEM", " - scsi: ufs: core: Include UTP error in INT_FATAL_ERRORS", " - ACPI: property: Return present device nodes only on fwnode interface", " - tools bitmap: Add missing asm-generic/bitsperlong.h include", " - tools: lib: thermal: don't preserve owner in install", " - tools: lib: thermal: use pkg-config to locate libnl3", " - rtc: pcf2127: fix watchdog interrupt mask on pcf2131", " - kbuild: uapi: Strip comments before size type check", " - ASoC: meson: aiu-encoder-i2s: fix bit clock polarity", " - ceph: add checking of wait_for_completion_killable() return value", " - ceph: refactor wake_up_bit() pattern of calling", " - ALSA: hda/realtek: Audio disappears on HP 15-fc000 after warm boot again", " - media: uvcvideo: Use heuristic to find stream entity", " - net: libwx: fix device bus LAN ID", " - riscv: Improve exception and system call latency", " - riscv: ptdump: use seq_puts() in pt_dump_seq_puts() macro", " - Bluetooth: btrtl: Fix memory leak in rtlbt_parse_firmware_v2()", " - net: dsa: tag_brcm: legacy: fix untagged rx on unbridged ports for", " bcm63xx", " - selftests/net: fix out-of-order delivery of FIN in gro:tcp test", " - selftests/net: use destination options instead of hop-by-hop", " - netdevsim: add Makefile for selftests", " - selftests: netdevsim: Fix ethtool-coalesce.sh fail by installing", " ethtool-common.sh", " - net: vlan: sync VLAN features with lower device", " - net: dsa: b53: fix resetting speed and pause on forced link", " - net: dsa: b53: fix enabling ip multicast", " - net: dsa: b53: stop reading ARL entries if search is done", " - sctp: Hold RCU read lock while iterating over address list", " - sctp: Hold sock lock while iterating over address list", " - bnxt_en: Fix a possible memory leak in bnxt_ptp_init", " - wifi: mac80211_hwsim: Limit destroy_on_close radio removal to netgroup", " - net/mlx5e: Use extack in get module eeprom by page callback", " - net/mlx5e: Fix return value in case of module EEPROM read error", " - net/mlx5e: SHAMPO, Fix skb size check for 64K pages", " - net: dsa: microchip: Fix reserved multicast address table programming", " - net: bridge: fix MST static key usage", " - tracing: Fix memory leaks in create_field_var()", " - drm/amd/display: Enable mst when it's detected but yet to be initialized", " - rtc: rx8025: fix incorrect register reference", " - x86/microcode/AMD: Add more known models to entry sign checking", " - smb: client: validate change notify buffer before copy", " - lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC", " - scsi: ufs: ufs-pci: Fix S0ix/S3 for Intel controllers", " - extcon: adc-jack: Cleanup wakeup source only if it was enabled", " - drm/amdgpu: Fix function header names in amdgpu_connectors.c", " - drm/amd/display: Fix black screen with HDMI outputs", " - riscv: stacktrace: fix backtracing through exceptions", " - selftests: netdevsim: set test timeout to 10 minutes", " - drm/i915: Fix conversion between clock ticks and nanoseconds", " - smb: client: fix refcount leak in smb2_set_path_attr", " - iommufd: Make vfio_compat's unmap succeed if the range is already empty", " - drm/amd: Fix suspend failure with secure display TA", " - compiler_types: Move unused static inline functions warning to W=2", " - RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid", " rfence errors", " - riscv: acpi: avoid errors caused by probing DT devices when ACPI is used", " - drm/amd/pm: Disable MCLK switching on SI at high pixel clocks", " - NFS4: Fix state renewals missing after boot", " - HID: quirks: avoid Cooler Master MM712 dongle wakeup bug", " - NFS: check if suid/sgid was cleared after a write as needed", " - HID: quirks: Add ALWAYS_POLL quirk for VRS R295 steering wheel", " - ASoC: max98090/91: fixed max98091 ALSA widget powering up/down", " - wifi: ath11k: zero init info->status in wmi_process_mgmt_tx_comp()", " - selftests: net: local_termination: Wait for interfaces to come up", " - net: fec: correct rx_bytes statistic for the case SHIFT16 is set", " - Bluetooth: 6lowpan: fix BDADDR_LE vs ADDR_LE_DEV address type confusion", " - Bluetooth: 6lowpan: Don't hold spin lock over sleeping functions", " - net/smc: fix mismatch between CLC header and proposal", " - net/handshake: Fix memory leak in tls_handshake_accept()", " - net: mdio: fix resource leak in mdiobus_register_device()", " - wifi: mac80211: skip rate verification for not captured PSDUs", " - net_sched: act_connmark: use RCU in tcf_connmark_dump()", " - net/mlx5e: Fix maxrate wraparound in threshold between units", " - net/mlx5e: Fix wraparound in rate limiting for values above 255 Gbps", " - net/mlx5e: Fix potentially misleading debug message", " - net_sched: limit try_bulk_dequeue_skb() batches", " - virtio-net: fix incorrect flags recording in big mode", " - hsr: Fix supervision frame sending on HSRv0", " - ACPI: CPPC: Check _CPC validity for only the online CPUs", " - ACPI: CPPC: Perform fast check switch only for online CPUs", " - ACPI: CPPC: Limit perf ctrs in PCC check only to online CPUs", " - Bluetooth: L2CAP: export l2cap_chan_hold for modules", " - cifs: stop writeback extension when change of size is detected", " - cifs: Fix uncached read into ITER_KVEC iterator", " - acpi,srat: Fix incorrect device handle check for Generic Initiator", " - regulator: fixed: fix GPIO descriptor leak on register failure", " - ASoC: cs4271: Fix regulator leak on probe failure", " - ASoC: codecs: va-macro: fix resource leak in probe error path", " - ASoC: tas2781: fix getting the wrong device number", " - pnfs: Fix TLS logic in _nfs4_pnfs_v4_ds_connect()", " - NFS: enable nconnect for RDMA", " - pnfs: Set transport security policy to RPC_XPRTSEC_NONE unless using TLS", " - NFS: sysfs: fix leak when nfs_client kobject add fails", " - NFSv4: Fix an incorrect parameter when calling nfs4_call_sync()", " - acpi/hmat: Fix lockdep warning for hmem_register_resource()", " - irqchip/riscv-intc: Add missing free() callback in riscv_intc_domain_ops", " - lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN", " - mtd: onenand: Pass correct pointer to IRQ handler", " - arm64: dts: rockchip: Set correct pinctrl for I2S1 8ch TX on odroid-m1", " - ARM: dts: imx51-zii-rdu1: Fix audmux node names", " - HID: hid-ntrig: Prevent memory leak in ntrig_report_version()", " - ARM: dts: BCM53573: Fix address of Luxul XAP-1440's Ethernet PHY", " - HID: uclogic: Fix potential memory leak in error path", " - KVM: SVM: Mark VMCB_LBR dirty when MSR_IA32_DEBUGCTLMSR is updated", " - gcov: add support for GCC 15", " - strparser: Fix signed/unsigned mismatch bug", " - dma-mapping: benchmark: Restore padding to ensure uABI remained", " consistent", " - LoongArch: Use correct accessor to read FWPC/MWPC", " - LoongArch: Let {pte,pmd}_modify() record the status of _PAGE_DIRTY", " - selftests/tracing: Run sample events to clear page cache events", " - wifi: mac80211: reject address change while connecting", " - mm/mm_init: fix hash table order logging in alloc_large_system_hash()", " - mmc: sdhci-of-dwcmshc: Change DLL_STRBIN_TAPNUM_DEFAULT to 0x4", " - crypto: hisilicon/qm - Fix device reference leak in qm_get_qos_value", " - smb: client: fix cifs_pick_channel when channel needs reconnect", " - spi: Try to get ACPI GPIO IRQ earlier", " - x86/microcode/AMD: Add Zen5 model 0x44, stepping 0x1 minrev", " - selftests/user_events: fix type cast for write_index packed member in", " perf_test", " - LoongArch: Use physical addresses for CSR_MERRENTRY/CSR_TLBRENTRY", " - EDAC/altera: Handle OCRAM ECC enable after warm reset", " - EDAC/altera: Use INTTEST register for Ethernet and USB SBE injection", " - btrfs: scrub: put bio after errors in scrub_raid56_parity_stripe()", " - btrfs: do not update last_log_commit when logging inode due to a new", " name", " - pmdomain: samsung: plug potential memleak during probe", " - selftests: mptcp: connect: fix fallback note due to OoO", " - selftests: mptcp: join: rm: set backup flag", " - selftests: mptcp: connect: trunc: read all recv data", " - Revert \"perf dso: Add missed dso__put to dso__load_kcore\"", " - mm, percpu: do not consider sleepable allocations atomic", " - netpoll: remove netpoll_srcu", " - net: netpoll: Individualize the skb pool", " - net: netpoll: flush skb pool during cleanup", " - scsi: ufs: core: Add UFSHCD_QUIRK_CUSTOM_CRYPTO_PROFILE", " - scsi: ufs: core: fold ufshcd_clear_keyslot() into its caller", " - scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_CRYPTO_ENABLE", " - scsi: ufs: core: Add fill_crypto_prdt variant op", " - scsi: ufs: core: Add UFSHCD_QUIRK_KEYS_IN_PRDT", " - scsi: ufs: core: Add a quirk for handling broken LSDBS field in", " controller capabilities register", " - scsi: ufs: core: Add a quirk to suppress link_startup_again", " - scsi: ufs: ufs-pci: Set UFSHCD_QUIRK_PERFORM_LINK_STARTUP_ONCE for Intel", " ADL", " - filemap: cap PTE range to be created to allowed zero fill in", " folio_map_range()", " - mm/memory: do not populate page table entries beyond i_size", " - mm/truncate: unmap large folio on split failure", " - net: netpoll: ensure skb_pool list is always initialized", " - memory tiers: use default_dram_perf_ref_source in log message", " - memcg: fix data-race KCSAN bug in rstats", " - s390/pci: Restore IRQ unconditionally for the zPCI device", " - wifi: ath11k: add support for MU EDCA", " - wifi: ath11k: avoid bit operation on key flags", " - wifi: mac80211: don't mark keys for inactive links as uploaded", " - wifi: mac80211: fix key tailroom accounting leak", " - kunit: test_dev_action: Correctly cast 'priv' pointer to long*", " - bpf: Find eligible subprogs for private stack support", " - bpf, x86: Avoid repeated usage of bpf_prog->aux->stack_depth", " - bpf: Do not audit capability check in do_jit()", " - Bluetooth: ISO: Update hci_conn_hash_lookup_big for Broadcast slave", " - Bluetooth: ISO: Fix BIS connection dst_type handling", " - dpll: spec: add missing module-name and clock-id to pin-get reply", " - ASoC: fsl_sai: Fix sync error in consumer mode", " - ACPI: fan: Use ACPI handle when retrieving _FST", " - drm/sched: avoid killing parent entity on child SIGKILL", " - drm/nouveau: Fix race in nouveau_sched_fini()", " - drm/ast: Clear preserved bits from register output value", " - drm/amd: Check that VPE has reached DPM0 in idle handler", " - drm/amd/display: Fix incorrect return of vblank enable on unconfigured", " crtc", " - firmware: qcom: scm: preserve assign_mem() error return value", " - soc: ti: pruss: don't use %pK through printk", " - bpf: Use tnums for JEQ/JNE is_branch_taken logic", " - ACPI: video: force native for Lenovo 82K8", " - libbpf: Fix USDT SIB argument handling causing unrecognized register", " error", " - ACPI: resource: Skip IRQ override on ASUS Vivobook Pro N6506CU", " - thermal: gov_step_wise: Allow cooling level to be reduced earlier", " - thermal: intel: selftests: workload_hint: Mask unsupported types", " - cpufreq: ondemand: Update the efficient idle check for Intel extended", " Families", " - pwm: pca9685: Use bulk write to atomicially update registers", " - i3c: mipi-i3c-hci-pci: Add support for Intel Wildcat Lake-U I3C", " - hwmon: (dell-smm) Remove Dell Precision 490 custom config data", " - selftests/bpf: Fix flaky bpf_cookie selftest", " - mfd: core: Increment of_node's refcount before linking it to the", " platform device", " - mfd: intel-lpss: Add Intel Wildcat Lake LPSS PCI IDs", " - drm/amdgpu: add range check for RAS bad page address", " - drm/amdgpu: Check vcn sram load return value", " - ASoC: mediatek: Use SND_JACK_AVOUT for HDMI/DP jacks", " - drm/amd/display: Reset apply_eamless_boot_optimization when dpms_off", " - wifi: rtw89: print just once for unknown C2H events", " - PCI/ERR: Update device error_state already after reset", " - scsi: ufs: host: mediatek: Fix PWM mode switch issue", " - HID: pidff: Use direction fix only for conditional effects", " - HID: pidff: PERMISSIVE_CONTROL quirk autodetection", " - wifi: rtw89: fix BSSID comparison for non-transmitted BSSID", " - dm error: mark as DM_TARGET_PASSES_INTEGRITY", " - bnxt_en: Add Hyper-V VF ID", " - idpf: do not linearize big TSO packets", " - net: wangxun: limit tx_max_coalesced_frames_irq", " - rpmsg: char: Export alias for RPMSG ID rpmsg-raw from table", " - net: ipv4: allow directed broadcast routes to use dst hint", " - scsi: mpi3mr: Fix I/O failures during controller reset", " - drm/amd/display: Support HW cursor 180 rot for any number of pipe splits", " - media: pci: mgb4: Fix timings comparison in VIDIOC_S_DV_TIMINGS", " - ASoC: SOF: ipc4-pcm: Add fixup for channels", " - drm/amdgpu: Avoid vcn v5.0.1 poison irq call trace on sriov guest", " - inet_diag: annotate data-races in inet_diag_bc_sk()", " - scsi: ufs: exynos: fsd: Gate ref_clk and put UFS device in reset on", " suspend", " - drm/xe/guc: Increase GuC crash dump buffer size", " - drm: panel-backlight-quirks: Make EDID match optional", " - PCI: imx6: Enable the Vaux supply if available", " - drm/xe/guc: Set upper limit of H2G retries over CTB", " - crypto: ccp: Skip SEV and SNP INIT for kdump boot", " - drm/amd/display: Fix pbn_div Calculation Error", " - tty/vt: Add missing return value for VT_RESIZE in vt_ioctl()", " - PCI: endpoint: pci-epf-test: Limit PCIe BAR size for fixed BARs", " - selftests: mptcp: join: allow more time to send ADD_ADDR", " - scsi: ufs: host: mediatek: Correct system PM flow", " - selftests: traceroute: Return correct value on failure", " - openrisc: Add R_OR1K_32_PCREL relocation type module support", " - wifi: mt76: mt76_eeprom_override to int", " - wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error", " - drm/amd/display: Set up pixel encoding for YCBCR422", " - drm/amd/display: fix dml ms order of operations", " - scsi: lpfc: Clean up allocated queues when queue setup mbox commands", " fail", " - scsi: lpfc: Decrement ndlp kref after FDISC retries exhausted", " - scsi: lpfc: Ensure PLOGI_ACC is sent prior to PRLI in Point to Point", " topology", " - wifi: rtw89: renew a completion for each H2C command waiting C2H event", " - usb: xhci-pci: add support for hosts with zero USB3 ports", " - RDMA/ipoib: Remove NULL check before dev_{put, hold}", " - IB/ipoib: Ignore L3 master device", " - bus: mhi: core: Improve mhi_sync_power_up handling for SYS_ERR state", " - wifi: mac80211: Track NAN interface start/stop", " - crypto: hisilicon/qm - invalidate queues in use", " - crypto: hisilicon/qm - adjust the internal processing sequence of the vf", " enable and disable", " - crypto: hisilicon/qm - clear all VF configurations in the hardware", " - selftests: forwarding: Reorder (ar)ping arguments to obey POSIX getopt", " - net: dsa: microchip: Set SPI as bus interface during reset for KSZ8463", " - drm/amd/display: Init dispclk from bootup clock for DCN314", " - drm/amd/display: Fix for test crash due to power gating", " - drm/amd/display: change dc stream color settings only in atomic commit", " - ACPI: scan: Update honor list for RPMI System MSI", " - vfio/pci: Fix INTx handling on legacy non-PCI 2.3 devices", " - Bluetooth: btusb: Add new VID/PID 13d3/3633 for MT7922", " - net: stmmac: est: Drop frames causing HLBS error", " - usb: xhci-pci: Fix USB2-only root hub registration", " - drm/amd/display: Add fallback path for YCBCR422", " - RDMA/hns: Fix recv CQ and QP cache affinity", " - clk: clocking-wizard: Fix output clock register offset for Versal", " platforms", " - LoongArch: Handle new atomic instructions for probes", " - net: wwan: t7xx: add support for HP DRMR-H01", " - ceph: fix potential race condition in ceph_ioctl_lazyio()", " - net: ionic: add dma_wmb() before ringing TX doorbell", " - net: ionic: map SKB after pseudo-header checksum prep", " - bnxt_en: Add mem_valid bit to struct bnxt_ctx_mem_type", " - bnxt_en: Refactor bnxt_free_ctx_mem()", " - bnxt_en: Add a 'force' parameter to bnxt_free_ctx_mem()", " - net: wan: framer: pef2256: Switch to devm_mfd_add_devices()", " - drm/amdgpu/smu: Handle S0ix for vangogh", " - drm/amd/display: update color on atomic commit time", " - drm/mediatek: Add pm_runtime support for GCE power control", " - arm64: kprobes: check the return value of set_memory_rox()", " - NFS4: Apply delay_retrans to async operations", " - HID: nintendo: Wait longer for initial probe", " - HID: logitech-hidpp: Add HIDPP_QUIRK_RESET_HI_RES_SCROLL", " - NFSD: Skip close replay processing if XDR encoding fails", " - net: ethernet: ti: am65-cpsw-qos: fix IET verify/response timeout", " - net: ethernet: ti: am65-cpsw-qos: fix IET verify retry mechanism", " - proc: fix the issue of proc_mem_open returning NULL", " - ext4: introduce ITAIL helper", " - LoongArch: KVM: Add delay until timer interrupt injected", " - nfsd: add missing FATTR4_WORD2_CLONE_BLKSIZE from supported attributes", " - ftrace: Fix BPF fexit with livepatch", " - btrfs: zoned: fix conventional zone capacity calculation", " - btrfs: release root after error in data_reloc_print_warning_inode()", " - pmdomain: imx: Fix reference count leak in imx_gpc_remove", " - selftests: mptcp: join: userspace: longer transfer", " - selftests: mptcp: join: properly kill background tasks", " - wifi: cfg80211: add an hrtimer based delayed work item", " - proc: proc_maps_open allow proc_mem_open to return NULL", " - Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_complete", " - Upstream stable to v6.6.117, v6.12.58, v6.12.59", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68204", " - pmdomain: arm: scmi: Fix genpd leak on provider registration failure", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-22107", " - net: dsa: sja1105: fix kasan out-of-bounds warning in", " sja1105_table_delete_entry()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-39981", " - Bluetooth: MGMT: Fix possible UAFs", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-22121", " - ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-23129", " - wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq()", " in error path", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40287", " - exfat: fix improper check of dentry.stream.valid_size", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40289", " - drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68201", " - drm/amdgpu: remove two invalid BUG_ON()s", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68180", " - drm/amd/display: Fix NULL deref in debugfs odm_combine_segments", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68322", " - parisc: Avoid crash due to unaligned access in unwinder", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40305", " - 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40307", " - exfat: validate cluster allocation bits of the allocation bitmap", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68190", " - drm/amdgpu/atom: Check kcalloc() for WS buffer in", " amdgpu_atom_execute_table_locked()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68315", " - f2fs: fix to detect potential corrupted nid in free_nid_list", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40339", " - drm/amdgpu: fix nullptr err of vm_handle_moved", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68311", " - tty: serial: ip22zilog: Use platform device for probing", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68313", " - x86/CPU/AMD: Add RDSEED fix for Zen5", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40360", " - drm/sysfb: Do not dereference NULL pointer in plane reset", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68734", " - isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40272", " - mm/secretmem: fix use-after-free race in fault handler", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40077", " - f2fs: fix to avoid overflow while left shift operation", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68245", " - net: netpoll: fix incorrect refcount handling causing incorrect cleanup", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40293", " - iommufd: Don't overflow during division for dirty tracking", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40303", " - btrfs: ensure no dirty metadata is written back for an fs with errors", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68184", " - drm/mediatek: Disable AFBC support on Mediatek DRM driver", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40268", " - cifs: client: fix memory leak in smb3_fs_context_parse_param", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40269", " - ALSA: usb-audio: Fix potential overflow of PCM transfer buffer", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40271", " - fs/proc: fix uaf in proc_readdir_de()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68241", " - ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68246", " - ksmbd: close accepted socket when per-IP limit rejects connection", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40273", " - NFSD: free copynotify stateid in nfs4_free_ol_stateid()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68208", " - bpf: account for current allocated stack depth in", " widen_imprecise_scalars()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68200", " - bpf: Add bpf_prog_run_data_pointers()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40275", " - ALSA: usb-audio: Fix NULL pointer dereference in", " snd_usb_mixer_controls_badd", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40277", " - drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40278", " - net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-", " infoleak", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40279", " - net: sched: act_connmark: initialize struct tc_ife to fix kernel leak", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40280", " - tipc: Fix use-after-free in tipc_mon_reinit_self().", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40281", " - sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40282", " - Bluetooth: 6lowpan: reset link-local header on ipv6 recv path", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40283", " - Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40284", " - Bluetooth: MGMT: cancel mesh send timer when hdev removed", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40285", " - smb/server: fix possible refcount leak in smb2_sess_setup()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40286", " - smb/server: fix possible memory leak in smb2_read()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40288", " - drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68244", " - drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40292", " - virtio-net: fix received length check in big packets", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40328", " - smb: client: fix potential UAF in smb2_close_cached_fid()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40294", " - Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40329", " - drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68320", " - lan966x: Fix sleeping in atomic context", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68192", " - net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40331", " - sctp: Prevent TOCTOU out-of-bounds write", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40301", " - Bluetooth: hci_event: validate skb length for unknown CC opcode", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40358", " - riscv: stacktrace: Disable KASAN checks for non-current tasks", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40304", " - fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68183", " - ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68173", " - ftrace: Fix softlockup in ftrace_module_enable", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40306", " - orangefs: fix xattr related buffer overflow...", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40308", " - Bluetooth: bcsp: receive data only if registered", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40309", " - Bluetooth: SCO: Fix UAF on sco_conn_free", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40310", " - amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40311", " - accel/habanalabs: support mapping cb with vmalloc-backed coherent memory", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68185", " - nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode", " dereferencing", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68176", " - PCI: cadence: Check for the existence of cdns_pcie::ops before using it", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68168", " - jfs: fix uninitialized waitqueue in transaction manager", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40312", " - jfs: Verify inode mode when loading from disk", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40333", " - f2fs: fix infinite loop in __insert_extent_tree()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68321", " - page_pool: always add GFP_NOWARN for ATOMIC allocations", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68191", " - udp_tunnel: use netdev_warn() instead of netdev_WARN()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40313", " - ntfs3: pretend $Extend records as regular files", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40314", " - usb: cdns3: gadget: Use-after-free during failed initialization and exit", " of cdnsp gadget", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40337", " - net: stmmac: Correctly handle Rx checksum offload errors", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68194", " - media: imon: make send_packet() more robust", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40363", " - net: ipv6: fix field-spanning memcpy warning in AH output", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68178", " - blk-cgroup: fix possible deadlock while configuring policy", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40341", " - futex: Don't leak robust_list pointer on exec race", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40342", " - nvme-fc: use lock accessing port_state and rport state", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40343", " - nvmet-fc: avoid scheduling association deletion twice", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68177", " - cpufreq/longhaul: handle NULL policy in longhaul_exit", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40315", " - usb: gadget: f_fs: Fix epfile null pointer access after ep enable.", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68310", " - s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68179", " - s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40317", " - regmap: slimbus: fix bus_context pointer in regmap init calls", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40318", " - Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68312", " - usbnet: Prevents free active kevent", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68172", " - crypto: aspeed - fix double free caused by devm", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40319", " - bpf: Sync pending IRQ work before freeing ring buffer", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-68171", " - x86/fpu: Ensure XFD state on signal delivery", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40320", " - smb: client: fix potential cfid UAF in smb2_query_info_compound", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40321", " - wifi: brcmfmac: fix crash while sending Action Frames in standalone AP", " Mode", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40322", " - fbdev: bitblit: bound-check glyph index in bit_putcs*", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40211", " - ACPI: video: Fix use-after-free in acpi_video_switch_brightness()", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40323", " - fbcon: Set fb_display[i]->mode to NULL when the mode is released", "", " * Noble update: upstream stable patchset 2026-01-30 (LP: #2139460) //", " CVE-2025-40324", " - NFSD: Fix crash in nfsd4_read_release()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282)", " - exec: Fix incorrect type for ret", " - hfs: clear offset and space out of valid records in b-tree node", " - hfs: make proper initalization of struct hfs_find_data", " - dlm: check for defined force value in dlm_lockspace_release", " - hfsplus: return EIO when type of hidden directory mismatch in", " hfsplus_fill_super()", " - lkdtm: fortify: Fix potential NULL dereference on kmalloc failure", " - m68k: bitops: Fix find_*_bit() signatures", " - powerpc/32: Remove PAGE_KERNEL_TEXT to fix startup failure", " - drivers/perf: hisi: Relax the event ID check in the framework", " - smb: server: let smb_direct_flush_send_list() invalidate a remote key", " first", " - Unbreak 'make tools/*' for user-space targets", " - net/mlx5e: Return 1 instead of 0 in invalid case in", " mlx5e_mpwrq_umr_entry_size()", " - rtnetlink: Allow deleting FDB entries in user namespace", " - net: enetc: correct the value of ENETC_RXB_TRUESIZE", " - dpaa2-eth: fix the pointer passed to PTR_ALIGN on Tx path", " - can: bxcan: bxcan_start_xmit(): use can_dev_dropped_skb() instead of", " can_dropped_invalid_skb()", " - selftests: net: fix server bind failure in sctp_vrf.sh", " - net/mlx5e: Reuse per-RQ XDP buffer to avoid stack zeroing overhead", " - net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for legacy RQ", " - arm64, mm: avoid always making PTE dirty in pte_mkwrite()", " - net: bonding: fix possible peer notify event loss or dup issue", " - dma-debug: don't report false positives with", " DMA_BOUNCE_UNALIGNED_KMALLOC", " - gpio: pci-idio-16: Define maximum valid register address offset", " - gpio: 104-idio-16: Define maximum valid register address offset", " - Revert \"cpuidle: menu: Avoid discarding useful information\"", " - ACPICA: Work around bogus -Wstringop-overread warning since GCC 11", " - can: netlink: can_changelink(): allow disabling of automatic restart", " - cifs: Fix TCP_Server_Info::credits to be signed", " - MIPS: Malta: Fix keyboard resource preventing i8042 driver from", " registering", " - net: stmmac: dwmac-rk: Fix disabling set_clock_selection", " - net: usb: rtl8150: Fix frame padding", " - net: ravb: Enforce descriptor type ordering", " - net: ravb: Ensure memory write completes before ringing TX doorbell", " - selftests: mptcp: join: mark 'flush re-add' as skipped if not supported", " - selftests: mptcp: join: mark implicit tests as skipped if not supported", " - spi: spi-nxp-fspi: add extra delay after dll locked", " - firmware: arm_scmi: Fix premature SCMI_XFER_FLAG_IS_RAW clearing in raw", " mode", " - RISC-V: Define pgprot_dmacoherent() for non-coherent devices", " - RISC-V: Don't print details of CPUs disabled in DT", " - hwmon: (sht3x) Fix error handling", " - gpio: ljca: Fix duplicated IRQ mapping", " - io_uring: correct __must_hold annotation in io_install_fixed_file", " - sched: Remove never used code in mm_cid_get()", " - USB: serial: option: add UNISOC UIS7720", " - USB: serial: option: add Quectel RG255C", " - USB: serial: option: add Telit FN920C04 ECM compositions", " - usb/core/quirks: Add Huawei ME906S to wakeup quirk", " - usb: raw-gadget: do not limit transfer length", " - xhci: dbc: enable back DbC in resume if it was enabled before suspend", " - x86/microcode: Fix Entrysign revision check for Zen1/Naples", " - binder: remove \"invalid inc weak\" check", " - mei: me: add wildcat lake P DID", " - misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup", " - tcpm: switch check for role_sw device with fw_node", " - dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp", " - serial: 8250_dw: handle reset control deassert error", " - serial: 8250_exar: add support for Advantech 2 port card with Device ID", " 0x0018", " - serial: 8250_mtk: Enable baud clock and manage in runtime PM", " - devcoredump: Fix circular locking dependency with devcd->mutex.", " - xfs: always warn about deprecated mount options", " - fuse: allocate ff->release_args only if release is needed", " - audit: record fanotify event regardless of presence of rules", " - perf: Use current->flags & PF_KTHREAD|PF_USER_WORKER instead of", " current->mm == NULL", " - perf: Have get_perf_callchain() return NULL if crosstask and user are", " set", " - perf: Skip user unwind if the task is a kernel thread", " - x86/bugs: Report correct retbleed mitigation status", " - x86/bugs: Fix reporting of LFENCE retpoline", " - EDAC/mc_sysfs: Increase legacy channel support to 16", " - btrfs: zoned: return error from btrfs_zone_finish_endio()", " - btrfs: zoned: refine extent allocator hint selection", " - btrfs: scrub: replace max_t()/min_t() with clamp() in", " scrub_throttle_dev_io()", " - btrfs: always drop log root tree reference in btrfs_replay_log()", " - btrfs: use level argument in log tree walk callback replay_one_buffer()", " - btrfs: use smp_mb__after_atomic() when forcing COW in", " create_pending_snapshot()", " - arch: Add the macro COMPILE_OFFSETS to all the asm-offsets.c", " - mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR", " - selftests: mptcp: disable add_addr retrans in endpoint_tests", " - selftests: mptcp: join: mark 'delete re-add signal' as skipped if not", " supported", " - serial: sc16is7xx: remove useless enable of enhanced features", " - xhci: dbc: poll at different rate depending on data transfer activity", " - xhci: dbc: Allow users to modify DbC poll interval via sysfs", " - xhci: dbc: Improve performance by removing delay in transfer event", " polling.", " - xhci: dbc: Avoid event polling busyloop if pending rx transfers are", " inactive.", " - xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall", " event", " - bits: add comments and newlines to #if, #else and #endif directives", " - bits: introduce fixed-type GENMASK_U*()", " - gpio: regmap: Allow to allocate regmap-irq device", " - gpio: regmap: add the .fixed_direction_output configuration parameter", " - gpio: idio-16: Define fixed direction of the GPIO lines", " - PCI: Test for bit underflow in pcie_set_readrq()", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - s390/mm: Use __GFP_ACCOUNT for user page table allocations", " - ptp: ocp: Fix typo using index 1 instead of i in SMA initialization loop", " - riscv: hwprobe: avoid uninitialized variable use in hwprobe_arch_id()", " - perf/x86/intel: Add ICL_FIXED_0_ADAPTIVE bit into INTEL_FIXED_BITS_MASK", " - cpuset: Use new excpus for nocpu error check when enabling root", " partition", " - btrfs: abort transaction on specific error places when walking log tree", " - btrfs: abort transaction in the process_one_buffer() log tree walk", " callback", " - btrfs: abort transaction if we fail to update inode in log replay dir", " fixup", " - btrfs: tree-checker: add inode extref checks", " - docs: kdoc: handle the obsolescensce of docutils.ErrorString()", " - bonding: return detailed error when loading native XDP fails", " - btrfs: tree-checker: fix bounds check in check_inode_extref()", " - Upstream stable to v6.6.115, v6.6.116, v6.12.56, v6.12.57", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-37860", " - sfc: fix NULL dereferences in ef100_process_design_param()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-21833", " - iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-22105", " - bonding: check xdp prog when set bond mode", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-38643", " - wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-23130", " - f2fs: fix to avoid panic once fallocation fails for pinfile", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40353", " - arm64: mte: Do not warn if the page is already tagged in copy_highpage()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-39678", " - platform/x86/amd/hsmp: Ensure sock->metric_tbl_addr is non-NULL", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40235", " - btrfs: directly free partially initialized fs_info in", " btrfs_check_leaked_roots()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40238", " - net/mlx5: Fix IPsec cleanup over MPV device", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40242", " - gfs2: Fix unlikely race in gdlm_put_lock", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40083", " - net/sched: sch_qfq: Fix null-deref in agg_dequeue", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40084", " - ksmbd: transport_ipc: validate payload size before reading handle", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40220", " - fuse: fix livelock in synchronous file put from fuseblk workers", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40237", " - fs/notify: call exportfs_encode_fid with s_umount", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-68249", " - most: usb: hdm_probe: Fix calling put_device() before device", " initialization", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40223", " - most: usb: Fix use-after-free in hdm_disconnect", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40106", " - comedi: fix divide-by-zero in comedi_buf_munge()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40226", " - firmware: arm_scmi: Account for failed debug initialization", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40231", " - vsock: fix lock inversion in vsock_assign_transport()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40233", " - ocfs2: clear extent cache after moving/defragmenting extents", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40346", " - arch_topology: Fix incorrect error check in", " topology_parse_cpu_capacity()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40240", " - sctp: avoid NULL dereference when chunk data buffer is missing", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40350", " - net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding", " RQ", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40347", " - net: enetc: fix the deadlock of enetc_mdio_lock", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40243", " - hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40351", " - hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40349", " - hfs: validate record offset in hfsplus_bmap_alloc", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40244", " - hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()", "", " * Noble update: upstream stable patchset 2026-01-29 (LP: #2139282) //", " CVE-2025-40245", " - nios2: ensure that memblock.current_limit is set when setting pfn limits", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267)", " - r8152: add error handling in rtl8152_driver_init", " - f2fs: fix wrong block mapping for multi-devices", " - jbd2: ensure that all ongoing I/O complete before freeing blocks", " - ext4: wait for ongoing I/O to complete before freeing blocks", " - btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation already", " running", " - btrfs: fix incorrect readahead expansion length", " - can: gs_usb: gs_make_candev(): populate net_device->dev_port", " - can: gs_usb: increase max interface to U8_MAX", " - drm/amdgpu: use atomic functions with memory barriers for vm fault info", " - drm/amd: Check whether secure display TA loaded successfully", " - cpufreq: CPPC: Avoid using CPUFREQ_ETERNAL as transition delay", " - epoll: Remove ep_scan_ready_list() in comments", " - eventpoll: Replace rwlock with spinlock", " - drm/msm/adreno: De-spaghettify the use of memory barriers", " - drm/exynos: exynos7_drm_decon: fix uninitialized crtc reference in", " functions", " - drm/exynos: exynos7_drm_decon: properly clear channels during bind", " - drm/exynos: exynos7_drm_decon: remove ctx->suspended", " - media: nxp: imx8-isi: Drop unused argument to mxc_isi_channel_chain()", " - usb: gadget: Store endpoint pointer in usb_request", " - usb: gadget: Introduce free_usb_request helper", " - HID: multitouch: fix sticky fingers", " - dax: skip read lock assertion for read-only filesystems", " - can: m_can: m_can_plat_remove(): add missing pm_runtime_disable()", " - net: dlink: handle dma_map_single() failure properly", " - doc: fix seg6_flowlabel path", " - r8169: fix packet truncation after S4 resume on RTL8168H/RTL8111H", " - amd-xgbe: Avoid spurious link down messages during interface toggle", " - tcp: fix tcp_tso_should_defer() vs large RTT", " - tg3: prevent use of uninitialized remote_adv and local_adv variables", " - tls: trim encrypted message to match the plaintext on short splice", " - net: tls: wait for async completion on last message", " - tls: wait for async encrypt in case of error during latter iterations of", " sendmsg", " - tls: always set record_type in tls_process_cmsg", " - tls: don't rely on tx_work during send()", " - net: usb: lan78xx: Add error handling to lan78xx_init_mac_address", " - net: usb: lan78xx: fix use of improperly initialized dev->chipid in", " lan78xx_reset", " - nvme-multipath: Skip nr_active increments in RETRY disposition", " - riscv: kprobes: Fix probe address validation", " - drm/bridge: lt9211: Drop check for last nibble of version register", " - ASoC: codecs: Fix gain setting ranges for Renesas IDT821034 codec", " - ASoC: nau8821: Cancel jdet_work before handling jack ejection", " - ASoC: nau8821: Generalize helper to clear IRQ status", " - ASoC: nau8821: Add DMI quirk to bypass jack debounce circuit", " - drm/i915/guc: Skip communication warning on reset in progress", " - drm/amd/powerplay: Fix CIK shutdown temperature", " - drm/rockchip: vop2: use correct destination rectangle height check", " - sched/balancing: Rename newidle_balance() => sched_balance_newidle()", " - sched/fair: Fix pelt lost idle time detection", " - ALSA: firewire: amdtp-stream: fix enum kernel-doc warnings", " - selftests/bpf: make arg_parsing.c more robust to crashes", " - HID: hid-input: only ignore 0 battery events for digitizers", " - HID: multitouch: fix name of Stylus input devices", " - selftests: arg_parsing: Ensure data is flushed to disk before reading.", " - arm64: cputype: Add Neoverse-V3AE definitions", " - arm64: errata: Apply workarounds for Neoverse-V3AE", " - NFSD: Rework encoding and decoding of nfsd4_deviceid", " - NFSD: Minor cleanup in layoutcommit processing", " - xfs: rename the old_crc variable in xlog_recover_process", " - xfs: fix log CRC mismatches between i386 and other architectures", " - PM: runtime: Add new devm functions", " - iio: imu: inv_icm42600: Simplify pm_runtime setup", " - phy: cdns-dphy: Store hs_clk_rate and return it", " - phy: cadence: cdns-dphy: Fix PLL lock and O_CMN_READY polling", " - iio: imu: inv_icm42600: reorganize DMA aligned buffers in structure", " - iio: imu: inv_icm42600: Avoid configuring if already pm_runtime", " suspended", " - quota: remove unneeded return value of register_quota_format", " - phy: cadence: cdns-dphy: Update calibration wait time for startup state", " machine", " - PCI: Add PCI_VDEVICE_SUB helper macro", " - ixgbevf: Add support for Intel(R) E610 device", " - ixgbevf: fix getting link speed data for E610 devices", " - nfsd: decouple the xprtsec policy check from check_nfsd_access()", " - PCI/sysfs: Ensure devices are powered for config reads (part 2)", " - ksmbd: browse interfaces list on FSCTL_QUERY_INTERFACE_INFO IOCTL", " - PCI: j721e: Enable ACSPCIE Refclk if \"ti,syscon-acspcie-proxy-ctrl\"", " exists", " - PCI: j721e: Fix programming sequence of \"strap\" settings", " - perf/core: Fix address filter match with backing files", " - perf/core: Fix MMAP event path names with backing files", " - perf/core: Fix MMAP2 event device with backing files", " - drm/msm/a6xx: Fix PDC sleep sequence", " - can: m_can: m_can_handle_state_errors(): fix CAN state transition to", " Error Active", " - can: m_can: m_can_chip_config(): bring up interface in correct state", " - drm/amdgpu: add ip offset support for cyan skillfish", " - drm/amdgpu: add support for cyan skillfish without IP discovery", " - drm/amdgpu: fix handling of harvesting for ip_discovery firmware", " - nvme/tcp: handle tls partially sent records in write_space()", " - nfsd: Use correct error code when decoding extents", " - nfsd: Drop dprintk in blocklayout xdr functions", " - NFSD: Implement large extent array support in pNFS", " - NFSD: Fix last write offset handling in layoutcommit", " - wifi: rtw89: avoid possible TX wait initialization race", " - xfs: use deferred intent items for reaping crosslinked blocks", " - md/raid0: Handle bio_split() errors", " - md/raid1: Handle bio_split() errors", " - md/raid10: Handle bio_split() errors", " - md: fix mssing blktrace bio split events", " - x86/resctrl: Refactor resctrl_arch_rmid_read()", " - x86/resctrl: Fix miscount of bandwidth event when reactivating", " previously unavailable RMID", " - d_alloc_parallel(): set DCACHE_PAR_LOOKUP earlier", " - dmaengine: Add missing cleanup on module unload", " - Upstream stable to v6.6.114, v6.12.55", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40105", " - vfs: Don't leak disconnected dentries on umount", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40092", " - usb: gadget: f_ncm: Refactor bind path to use __free()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40101", " - btrfs: fix memory leaks when rejecting a non SINGLE data profile without", " an RST", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40166", " - drm/xe/guc: Check GuC running state before deregistering exec queue", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40104", " - ixgbevf: fix mailbox API compatibility by negotiating supported features", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40087", " - NFSD: Define a proc_layoutcommit for the FlexFiles layout type", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40196", " - fs: quota: create dedicated workqueue for quota_release_work", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40088", " - hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40085", " - ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40172", " - accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40176", " - tls: wait for pending async decryptions if tls_strp_msg_hold fails", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40173", " - net/ip6_tunnel: Prevent perpetual tunnel growth", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40095", " - usb: gadget: f_rndis: Refactor bind path to use __free()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40094", " - usb: gadget: f_acm: Refactor bind path to use __free()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40093", " - usb: gadget: f_ecm: Refactor bind path to use __free()", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40165", " - media: nxp: imx8-isi: m2m: Fix streaming cleanup on release", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40096", " - drm/sched: Fix potential double free in", " drm_sched_job_add_resv_dependencies", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40099", " - cifs: parse_dfs_referrals: prevent oob on malformed input", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40100", " - btrfs: do not assert we found block group item when creating free space", " tree", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40167", " - ext4: detect invalid INLINE_DATA + EXTENTS flag combination", "", " * Noble update: upstream stable patchset 2026-01-28 (LP: #2139267) //", " CVE-2025-40103", " - smb: client: Fix refcount leak for cifs_sb_tlink", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158)", " - fs: always return zero on success from replace_fd()", " - fscontext: do not consume log entries when returning -EMSGSIZE", " - clocksource/drivers/clps711x: Fix resource leaks in error paths", " - iio: frequency: adf4350: Fix ADF4350_REG3_12BIT_CLKDIV_MODE", " - asm-generic/io.h: Skip trace helpers if rwmmio events are disabled", " - perf evsel: Avoid container_of on a NULL leader", " - libperf event: Ensure tracing data is multiple of 8 sized", " - clk: at91: peripheral: fix return value", " - perf util: Fix compression checks returning -1 as bool", " - rtc: x1205: Fix Xicor X1205 vendor prefix", " - rtc: optee: fix memory leak on driver removal", " - perf arm_spe: Correct setting remote access", " - perf arm-spe: Rename the common data source encoding", " - perf arm_spe: Correct memory level for remote access", " - perf session: Fix handling when buffer exceeds 2 GiB", " - perf test: Don't leak workload gopipe in PERF_RECORD_*", " - perf test: Add a test for default perf stat command", " - perf tools: Add fallback for exclude_guest", " - perf evsel: Ensure the fallback message is always written to", " - clk: mediatek: mt8195-infra_ao: Fix parent for infra_ao_hdmi_26m", " - clk: mediatek: clk-mux: Do not pass flags to", " clk_mux_determine_rate_flags()", " - clk: nxp: lpc18xx-cgu: convert from round_rate() to determine_rate()", " - clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver", " - clk: tegra: do not overallocate memory for bpmp clocks", " - ASoC: SOF: ipc4-topology: Correct the minimum host DMA buffer size", " - LoongArch: Remove CONFIG_ACPI_TABLE_UPGRADE in platform_init()", " - LoongArch: Init acpi_gbl_use_global_lock to false", " - net/mlx4: prevent potential use after free in mlx4_en_do_uc_filter()", " - drm/vmwgfx: Fix copy-paste typo in validation", " - tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request().", " - net: fsl_pq_mdio: Fix device node reference leak in fsl_pq_mdio_probe", " - tools build: Align warning options with perf", " - perf python: split Clang options when invoking Popen", " - tcp: take care of zero tp->window_clamp in tcp_set_rcvlowat()", " - mailbox: zynqmp-ipi: Remove redundant mbox_controller_unregister() call", " - mailbox: zynqmp-ipi: Remove dev.parent check in zynqmp_ipi_free_mboxes", " - drm/amdgpu: Add additional DCE6 SCL registers", " - drm/amd/display: Add missing DCE6 SCL_HORZ_FILTER_INIT* SRIs", " - drm/amd/display: Properly clear SCL_*_FILTER_CONTROL on DCE6", " - drm/amd/display: Properly disable scaling on DCE6", " - netfilter: nf_tables: drop unused 3rd argument from validate callback", " ops", " - bridge: br_vlan_fill_forward_path_pvid: use br_vlan_group_rcu()", " - smb: client: fix missing timestamp updates after utime(2)", " - tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single", " - gpio: wcd934x: mark the GPIO controller as sleeping", " - bpf: Avoid RCU context warning when unpinning htab with internal structs", " - ACPI: property: Fix buffer properties extraction for subnodes", " - ACPI: TAD: Add missing sysfs_remove_group() for ACPI_TAD_RT", " - ACPI: debug: fix signedness issues in read/write helpers", " - arm64: dts: qcom: msm8916: Add missing MDSS reset", " - arm64: dts: qcom: msm8939: Add missing MDSS reset", " - arm64: dts: qcom: sdm845: Fix slimbam num-channels/ees", " - arm64: dts: ti: k3-am62a-main: Fix main padcfg length", " - ARM: OMAP2+: pm33xx-core: ix device node reference leaks in", " amx3_idle_init", " - dt-bindings: phy: rockchip-inno-csi-dphy: make power-domains non-", " required", " - xen/events: Cleanup find_virq() return codes", " - xen/manage: Fix suspend error path", " - xen/events: Update virq_to_irq on migration", " - firmware: meson_sm: fix device leak at probe", " - media: cx18: Add missing check after DMA map", " - media: i2c: mt9v111: fix incorrect type for ret", " - media: mc: Fix MUST_CONNECT handling for pads with no links", " - media: pci: ivtv: Add missing check after DMA map", " - media: venus: firmware: Use correct reset sequence for IRIS2", " - media: lirc: Fix error handling in lirc_register()", " - drm/rcar-du: dsi: Fix 1/2/3 lane support", " - drm/nouveau: fix bad ret code in nouveau_bo_move_prep", " - blk-crypto: fix missing blktrace bio split events", " - bus: mhi: ep: Fix chained transfer handling in read path", " - bus: mhi: host: Do not use uninitialized 'dev' pointer in", " mhi_init_irq_setup()", " - copy_sighand: Handle architectures where sizeof(unsigned long) <", " sizeof(u64)", " - crypto: aspeed - Fix dma_unmap_sg() direction", " - crypto: atmel - Fix dma_unmap_sg() direction", " - crypto: rockchip - Fix dma_unmap_sg() nents value", " - fbdev: Fix logic error in \"offb\" name match", " - fs/ntfs3: Fix a resource leak bug in wnd_extend()", " - iio: dac: ad5360: use int type to store negative error codes", " - iio: dac: ad5421: use int type to store negative error codes", " - iio: frequency: adf4350: Fix prescaler usage.", " - iio: xilinx-ams: Fix AMS_ALARM_THR_DIRECT_MASK", " - iio: xilinx-ams: Unmask interrupts after updating alarms", " - init: handle bootloader identifier in kernel parameters", " - iio: imu: inv_icm42600: Drop redundant pm_runtime reinitialization in", " resume", " - iommu/vt-d: PRS isn't usable if PDS isn't supported", " - KEYS: trusted_tpm1: Compare HMAC values in constant time", " - lib/genalloc: fix device leak in of_gen_pool_get()", " - of: unittest: Fix device reference count leak in", " of_unittest_pci_node_verify", " - openat2: don't trigger automounts with RESOLVE_NO_XDEV", " - parisc: don't reference obsolete termio struct for TC* constants", " - parisc: Remove spurious if statement from raw_copy_from_user()", " - nvme-pci: Add TUXEDO IBS Gen8 to Samsung sleep quirk", " - pinctrl: samsung: Drop unused S3C24xx driver data", " - power: supply: max77976_charger: fix constant current reporting", " - powerpc/powernv/pci: Fix underflow and leak issue", " - powerpc/pseries/msi: Fix potential underflow and leak issue", " - sched/deadline: Fix race in push_dl_task()", " - scsi: hpsa: Fix potential memory leak in hpsa_big_passthru_ioctl()", " - sparc64: fix hugetlb for sun4u", " - sparc: fix error handling in scan_one_device()", " - mtd: rawnand: fsmc: Default to autodetect buswidth", " - mmc: core: SPI mode remove cmd7", " - memory: samsung: exynos-srom: Fix of_iomap leak in exynos_srom_probe", " - rtc: interface: Ensure alarm irq is enabled when UIE is enabled", " - rtc: interface: Fix long-standing race when setting alarm", " - rseq/selftests: Use weak symbol reference, not definition, to link with", " glibc", " - PCI: tegra: Convert struct tegra_msi mask_lock into raw spinlock", " - PCI/sysfs: Ensure devices are powered for config reads", " - PCI/ERR: Fix uevent on failure to recover", " - PCI/AER: Fix missing uevent on recovery when a reset is requested", " - PCI/AER: Support errors introduced by PCIe r6.0", " - PCI: keystone: Use devm_request_irq() to free \"ks-pcie-error-irq\" on", " exit", " - PCI: rcar-host: Drop PMSR spinlock", " - PCI: rcar-host: Convert struct rcar_msi mask_lock into raw spinlock", " - PCI: tegra194: Fix broken tegra_pcie_ep_raise_msi_irq()", " - PCI: tegra194: Handle errors in BPMP response", " - spi: cadence-quadspi: Flush posted register writes before INDAC access", " - spi: cadence-quadspi: Flush posted register writes before DAC access", " - x86/umip: Check that the instruction opcode is at least two bytes", " - x86/umip: Fix decoding of register forms of 0F 01 (SGDT and SIDT", " aliases)", " - selftests: mptcp: join: validate C-flag + def limit", " - wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again", " - wifi: mt76: mt7921u: Add VID/PID for Netgear A7500", " - mm/page_alloc: only set ALLOC_HIGHATOMIC for __GPF_HIGH allocations", " - mm/hugetlb: early exit from hugetlb_pages_alloc_boot() when", " max_huge_pages=0", " - NFSD: Fix destination buffer size in nfsd4_ssc_setup_dul()", " - nfsd: nfserr_jukebox in nlm_fopen should lead to a retry", " - ext4: increase i_disksize to offset + len in", " ext4_update_disksize_before_punch()", " - ext4: correctly handle queries for metadata mappings", " - ext4: fix an off-by-one issue during moving extents", " - ext4: guard against EA inode refcount underflow in xattr update", " - ext4: validate ea_ino and size in check_xattrs", " - ACPICA: Allow to skip Global Lock initialization", " - ext4: free orphan info with kvfree", " - lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older", " - Squashfs: add additional inode sanity checking", " - media: mc: Clear minor number before put device", " - mfd: intel_soc_pmic_chtdc_ti: Fix invalid regmap-config max_register", " value", " - mfd: intel_soc_pmic_chtdc_ti: Drop unneeded assignment for cache_type", " - mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag", " - ksmbd: add max ip connections parameter", " - misc: fastrpc: Add missing dev_err newlines", " - misc: fastrpc: Save actual DMA size in fastrpc_map structure", " - PCI: endpoint: Remove surplus return statement from", " pci_epf_test_clean_dma_chan()", " - btrfs: fix the incorrect max_bytes value for find_lock_delalloc_range()", " - KVM: SVM: Emulate PERF_CNTR_GLOBAL_STATUS_SET for PerfMonV2", " - ipmi: Fix handling of messages with provided receive message pointer", " - arm64: kprobes: call set_memory_rox() for kprobe page", " - arm64: mte: Do not flag the zero page as PG_mte_tagged", " - ACPI: battery: allocate driver data through devm_ APIs", " - ACPI: battery: initialize mutexes through devm_ APIs", " - ACPI: battery: Check for error code from devm_mutex_init() call", " - ACPI: battery: Add synchronization between interface updates", " - ACPI: property: Disregard references in data-only subnode lists", " - ACPI: property: Add code comments explaining what is going on", " - ACPI: property: Do not pass NULL handles to acpi_attach_data()", " - s390/bpf: Change seen_reg to a mask", " - s390/bpf: Centralize frame offset calculations", " - s390/bpf: Describe the frame using a struct instead of constants", " - s390/bpf: Write back tail call counter for BPF_PSEUDO_CALL", " - s390/bpf: Write back tail call counter for BPF_TRAMP_F_CALL_ORIG", " - selftests/mm: skip soft-dirty tests when CONFIG_MEM_SOFT_DIRTY is", " disabled", " - mptcp: pm: in-kernel: usable client side with C-flag", " - irqchip/sifive-plic: Make use of __assign_bit()", " - irqchip/sifive-plic: Avoid interrupt ID 0 handling during suspend/resume", " - minixfs: Verify inode mode when loading from disk", " - fs: Add 'initramfs_options' to set initramfs mount options", " - cramfs: Verify inode mode when loading from disk", " - writeback: Avoid softlockup when switching many inodes", " - writeback: Avoid excessively long inode switching times", " - perf test stat: Avoid hybrid assumption when virtualized", " - rseq: Protect event mask against membarrier IPI", " - perf vendor events arm64 AmpereOneX: Fix typo - should be", " l1d_cache_access_prefetches", " - ASoC: SOF: ipc4-topology: Account for different ChainDMA host buffer", " size", " - ASoC: SOF: Intel: hda-pcm: Place the constraint on period time instead", " of buffer time", " - ASoC: SOF: Intel: Read the LLP via the associated Link DMA channel", " - s390/cio: Update purge function to unregister the unused subchannels", " - mailbox: mtk-cmdq-mailbox: Switch to __pm_runtime_put_autosuspend()", " - mailbox: mtk-cmdq: Switch to pm_runtime_put_autosuspend()", " - mailbox: mtk-cmdq: Remove pm_runtime APIs from cmdq_mbox_send_data()", " - cifs: Fix copy_to_iter return value check", " - ARM: AM33xx: Implement TI advisory 1.0.36 (EMU0/EMU1 pins state on", " reset)", " - media: s5p-mfc: remove an unused/uninitialized variable", " - media: ti: j721e-csi2rx: Use devm_of_platform_populate", " - media: ti: j721e-csi2rx: Fix source subdev link creation", " - drm/xe/uapi: loosen used tracking restriction", " - PCI: xilinx-nwl: Fix ECAM programming", " - PCI: tegra194: Reset BARs when running in PCIe endpoint mode", " - s390: Add -Wno-pointer-sign to KBUILD_CFLAGS_DECOMPRESSOR", " - wifi: mt76: mt7925u: Add VID/PID for Netgear A9000", " - ext4: add ext4_sb_bread_nofail() helper function for", " ext4_free_branches()", " - mm/ksm: fix incorrect KSM counter handling in mm_struct during fork", " - KVM: x86: Advertise SRSO_USER_KERNEL_NO to userspace", " - copy_file_range: limit size if in compat mode", " - Upstream stable to v6.6.113, v6.12.54", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40198", " - ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40159", " - xsk: Harden userspace-supplied xdp_desc validation", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40221", " - media: pci: mg4b: fix uninitialized iio scan data", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40180", " - mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40178", " - pid: Add a judgment for ns null in pid_nr_ns", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40202", " - ipmi: Rework user message limit handling", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40032", " - PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before", " release", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40038", " - KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40042", " - tracing: Fix race condition in kprobe initialization causing NULL", " pointer dereference", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40200", " - Squashfs: reject negative file sizes in squashfs_read_inode()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40179", " - ext4: verify orphan file size is not too big", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40218", " - mm/damon/vaddr: do not repeat pte_offset_map_lock() until success", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40219", " - PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40193", " - xtensa: simdisk: add input size check in proc_write_simdisk", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40204", " - sctp: Fix MAC comparison to be constant-time", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40192", " - Revert \"ipmi: fix msg stack when IPMI is disconnected\"", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40188", " - pwm: berlin: Fix wrong register in suspend/resume", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40201", " - kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in", " sys_prlimit64() paths", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40194", " - cpufreq: intel_pstate: Fix object lifecycle issue in", " update_qos_request()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40205", " - btrfs: avoid potential out-of-bounds in btrfs_encode_fh()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40160", " - xen/events: Return -EEXIST for bound VIRQs", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40206", " - netfilter: nft_objref: validate objref and objrefmap expressions", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40183", " - bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40187", " - net/sctp: fix a null dereference in sctp_disposition", " sctp_sf_do_5_1D_ce()", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40111", " - drm/vmwgfx: Fix Use-after-free in validation", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40110", " - drm/vmwgfx: Fix a null-ptr access in the cursor snooper", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40001", " - scsi: mvsas: Fix use-after-free bugs in mvs_work_queue", "", " * Noble update: upstream stable patchset 2026-01-27 (LP: #2139158) //", " CVE-2025-40207", " - media: v4l2-subdev: Fix alloc failure check in", " v4l2_subdev_call_state_try()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072)", " - media: tunner: xc5000: Refactor firmware load", " - USB: serial: option: add SIMCom 8230C compositions", " - wifi: rtlwifi: rtl8192cu: Don't claim USB ID 07b8:8188", " - ASoC: amd: acp: Adjust pdm gain value", " - dm-integrity: limit MAX_TAG_SIZE to 255", " - platform/x86/amd/pmc: Add MECHREVO Yilong15Pro to spurious_8042 list", " - perf subcmd: avoid crash in exclude_cmds when excludes is empty", " - ASoC: rt5682s: Adjust SAR ADC button mode to fix noise issue", " - btrfs: ref-verify: handle damaged extent root tree", " - can: rcar_canfd: Fix controller mode setting", " - platform/x86/amd/pmc: Add Stellaris Slim Gen6 AMD to spurious 8042", " quirks list", " - ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free", " - hid: fix I2C read buffer overflow in raw_event() for mcp2221", " - serial: stm32: allow selecting console when the driver is module", " - [Config] enable SERIAL_STM32_CONSOLE", " - staging: axis-fifo: fix maximum TX packet length check", " - staging: axis-fifo: fix TX handling on copy_from_user() failure", " - staging: axis-fifo: flush RX FIFO on read errors", " - driver core/PM: Set power.no_callbacks along with power.no_pm", " - riscv: mm: Use hint address in mmap if available", " - riscv: mm: Do not restrict mmap address based on hint", " - filelock: add FL_RECLAIM to show_fl_flags() macro", " - init: INITRAMFS_PRESERVE_MTIME should depend on BLK_DEV_INITRD", " - seccomp: Fix a race with WAIT_KILLABLE_RECV if the tracer replies too", " fast", " - selftests: arm64: Check fread return value in exec_target", " - gfs2: Fix GLF_INVALIDATE_IN_PROGRESS flag clearing in do_xmote", " - coresight: trbe: Prevent overflow in PERF_IDX2OFF()", " - perf: arm_spe: Prevent overflow in PERF_IDX2OFF()", " - smb: server: fix IRD/ORD negotiation with the client", " - x86/vdso: Fix output operand size of RDPID", " - arm64: dts: renesas: rzg2lc-smarc: Disable CAN-FD channel0", " - regmap: Remove superfluous check for !config in __regmap_init()", " - bpf/selftests: Fix test_tcpnotify_user", " - bpf: Remove migrate_disable in kprobe_multi_link_prog_run", " - libbpf: Fix reuse of DEVMAP", " - ARM: dts: renesas: porter: Fix CAN pin group", " - leds: flash: leds-qcom-flash: Update torch current clamp setting", " - cpufreq: scmi: Account for malformed DT in scmi_dev_used_by_cpus()", " - ACPI: processor: idle: Fix memory leak when register cpuidle device", " failed", " - soc: qcom: rpmh-rsc: Unconditionally clear _TRIGGER bit for TCS", " - pinctrl: meson-gxl: add missing i2c_d pinmux", " - blk-mq: check kobject state_in_sysfs before deleting in", " blk_mq_unregister_hctx", " - ARM: at91: pm: fix MCKx restore routine", " - arm64: dts: apple: t8103-j457: Fix PCIe ethernet iommu-map", " - regulator: scmi: Use int type to store negative error codes", " - selftests/nolibc: fix EXPECT_NZ macro", " - block: use int to store blk_stack_limits() return value", " - PM: sleep: core: Clear power.must_resume in noirq suspend error path", " - ARM: dts: ti: omap: am335x-baltos: Fix ti,en-ck32k-xtal property in DTS", " to use correct boolean syntax", " - ARM: dts: ti: omap: omap3-devkit8000-lcd: Fix ti,keep-vref-on property", " to use correct boolean syntax in DTS", " - ARM: dts: omap: am335x-cm-t335: Remove unused mcasp num-serializer", " property", " - PM / devfreq: mtk-cci: Fix potential error pointer dereference in", " probe()", " - power: supply: cw2015: Fix a alignment coding style issue", " - pinctrl: renesas: Use int type to store negative error codes", " - null_blk: Fix the description of the cache_size module argument", " - arm64: dts: mediatek: mt8195: Remove suspend-breaking reset from pcie0", " - nbd: restrict sockets to TCP and UDP", " - firmware: firmware: meson-sm: fix compile-test default", " - cpuidle: qcom-spm: fix device and OF node leaks at probe", " - arm64: dts: mediatek: mt6331: Fix pmic, regulators, rtc, keys node names", " - arm64: dts: mediatek: mt6795-xperia-m5: Fix mmc0 latch-ck value", " - arm64: dts: mediatek: mt8516-pumpkin: Fix machine compatible", " - pwm: tiehrpwm: Fix corner case in clock divisor calculation", " - ACPICA: Fix largest possible resource descriptor index", " - nvmet-fc: move lsop put work to nvmet_fc_ls_req_op", " - i3c: master: svc: Use manual response for IBI events", " - i3c: master: svc: Recycle unused IBI slot", " - selftests: watchdog: skip ping loop if WDIOF_KEEPALIVEPING not supported", " - bpf: Explicitly check accesses to bpf_sock_addr", " - smp: Fix up and expand the smp_call_function_many() kerneldoc", " - tools/nolibc: make time_t robust if __kernel_old_time_t is missing in", " host headers", " - once: fix race by moving DO_ONCE to separate section", " - hwmon: (mlxreg-fan) Separate methods of fan setting coming from", " different subsystems", " - thermal/drivers/qcom: Make LMH select QCOM_SCM", " - thermal/drivers/qcom/lmh: Add missing IRQ includes", " - i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD", " - i2c: designware: Fix clock issue when PM is disabled", " - i2c: designware: Add disabling clocks when probe fails", " - bpf: Enforce expected_attach_type for tailcall compatibility", " - drm/panel: novatek-nt35560: Fix invalid return value", " - drm/radeon/r600_cs: clean up of dead code in r600_cs", " - f2fs: fix condition in __allow_reserved_blocks()", " - drm/bridge: it6505: select REGMAP_I2C", " - media: zoran: Remove zoran_fh structure", " - phy: rockchip: naneng-combphy: Enable U3 OTG port for RK3568", " - usb: host: max3421-hcd: Fix error pointer dereference in probe cleanup", " - usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure calls", " - serial: max310x: Add error checking in probe()", " - drm/amd/display: Remove redundant semicolons", " - crypto: keembay - Add missing check after sg_nents_for_len()", " - hwrng: nomadik - add ARM_AMBA dependency", " - scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod", " - scsi: myrs: Fix dma_alloc_coherent() error check", " - media: rj54n1cb0c: Fix memleak in rj54n1_probe()", " - RDMA/mlx5: Fix vport loopback forcing for MPV device", " - ALSA: lx_core: use int type to store negative error codes", " - media: st-delta: avoid excessive stack usage", " - crypto: hisilicon/zip - remove unnecessary validation for high-", " performance mode configurations", " - crypto: hisilicon - re-enable address prefetch after device resuming", " - crypto: hisilicon/qm - check whether the input function and PF are on", " the same device", " - inet: ping: check sock_net() in ping_get_port() and ping_lookup()", " - coresight: Only register perf symlink for sinks with alloc_buffer", " - drm/amdgpu: Power up UVD 3 for FW validation (v2)", " - drm/amd/pm: Disable ULV even if unsupported (v3)", " - drm/amd/pm: Fix si_upload_smc_data (v3)", " - drm/amd/pm: Adjust si_upload_smc_data register programming (v3)", " - drm/amd/pm: Treat zero vblank time as too short in si_dpm (v3)", " - drm/amd/pm: Disable MCLK switching with non-DC at 120 Hz+ (v2)", " - drm/amd/pm: Disable SCLK switching on Oland with high pixel clocks (v3)", " - wifi: mwifiex: send world regulatory domain to driver", " - PCI: tegra: Fix devm_kcalloc() argument order for port->phys allocation", " - tcp: fix __tcp_close() to only send RST when required", " - drm/amdkfd: Fix error code sign for EINVAL in svm_ioctl()", " - usb: phy: twl6030: Fix incorrect type for ret", " - usb: gadget: configfs: Correctly set use_os_string at bind", " - tty: n_gsm: Don't block input queue by waiting MSC", " - misc: genwqe: Fix incorrect cmd field being reported in error", " - pps: fix warning in pps_register_cdev when register device fail", " - ASoC: Intel: bytcht_es8316: Fix invalid quirk input mapping", " - ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping", " - ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping", " - drm/msm/dpu: fix incorrect type for ret", " - fs: ntfs3: Fix integer overflow in run_unpack()", " - fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist", " - iio: consumers: Fix handling of negative channel scale in", " iio_convert_raw_to_processed()", " - iio: consumers: Fix offset handling in iio_convert_raw_to_processed()", " - netfilter: ipset: Remove unused htable_bits in macro ahash_region", " - ipvs: Use READ_ONCE/WRITE_ONCE for ipvs->enable", " - watchdog: mpc8xxx_wdt: Reload the watchdog timer when enabling the", " watchdog", " - drivers/base/node: handle error properly in register_one_node()", " - RDMA/cm: Rate limit destroy CM ID timeout error message", " - wifi: mt76: fix potential memory leak in mt76_wmac_probe()", " - f2fs: fix to update map->m_next_extent correctly in f2fs_map_blocks()", " - f2fs: fix to truncate first page in error path of f2fs_truncate()", " - f2fs: fix to mitigate overhead of f2fs_zero_post_eof_page()", " - ACPI: NFIT: Fix incorrect ndr_desc being reportedin dev_err message", " - scsi: qla2xxx: edif: Fix incorrect sign of error code", " - scsi: qla2xxx: Fix incorrect sign of error code in START_SP_W_RETRIES()", " - scsi: qla2xxx: Fix incorrect sign of error code in qla_nvme_xmt_ls_rsp()", " - f2fs: fix zero-sized extent for precache extents", " - RDMA/core: Resolve MAC of next-hop device without ARP support", " - IB/sa: Fix sa_local_svc_timeout_ms read race", " - Documentation: trace: historgram-design: Separate sched_waking histogram", " section heading and the following diagram", " - wifi: mac80211: fix Rx packet handling when pubsta information is not", " available", " - sparc: fix accurate exception reporting in copy_{from_to}_user for", " UltraSPARC", " - sparc: fix accurate exception reporting in copy_{from_to}_user for", " UltraSPARC III", " - sparc: fix accurate exception reporting in copy_{from_to}_user for", " Niagara", " - sparc: fix accurate exception reporting in copy_to_user for Niagara 4", " - sparc: fix accurate exception reporting in copy_{from,to}_user for M7", " - vfio/pds: replace bitmap_free with vfree", " - crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs", " - RDMA/rxe: Fix race in do_task() when draining", " - wifi: rtw89: avoid circular locking dependency in ser_state_run()", " - PCI: tegra194: Fix duplicate PLL disable in", " pex_ep_event_pex_rst_assert()", " - remoteproc: qcom: q6v5: Avoid disabling handover IRQ twice", " - coresight-etm4x: Conditionally access register TRCEXTINSELR", " - coresight: etm4x: Support atclk", " - coresight: trbe: Return NULL pointer for allocation failures", " - NFSv4.1: fix backchannel max_resp_sz verification check", " - scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()", " - usb: vhci-hcd: Prevent suspending virtually attached devices", " - RDMA/siw: Always report immediate post SQ errors", " - net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast", " - vhost: vringh: Fix copy_to_iter return value check", " - Bluetooth: MGMT: Fix not exposing debug UUID on", " MGMT_OP_READ_EXP_FEATURES_INFO", " - Bluetooth: ISO: Fix possible UAF on iso_conn_free", " - Bluetooth: ISO: don't leak skb in ISO_CONT RX", " - Bluetooth: hci_sync: Fix using random address for BIG/PA advertisements", " - KEYS: X.509: Fix Basic Constraints CA flag parsing", " - hwrng: ks-sa - fix division by zero in ks_sa_rng_init", " - ocfs2: fix double free in user_cluster_connect()", " - drivers/base/node: fix double free in register_one_node()", " - mtd: rawnand: atmel: Fix error handling path in", " atmel_nand_controller_add_nands", " - nfp: fix RSS hash key size when RSS is not supported", " - net: ena: return 0 in ena_get_rxfh_key_size() when RSS hash key is not", " configurable", " - net: dlink: handle copy_thresh allocation failure", " - net/mlx5: Stop polling for command response if interface goes down", " - net/mlx5: pagealloc: Fix reclaim race during command interface teardown", " - net/mlx5: fw reset, add reset timeout work", " - smb: client: fix crypto buffers in non-linear memory", " - vhost: vringh: Modify the return value check", " - bpf: Reject negative offsets for ALU ops", " - Squashfs: fix uninit-value in squashfs_get_parent", " - uio_hv_generic: Let userspace take care of interrupt mask", " - ASoC: wcd934x: fix error handling in wcd934x_codec_parse_data()", " - ASoC: SOF: ipc3-topology: Fix multi-core and static pipelines tear down", " - fs: udf: fix OOB read in lengthAllocDescs handling", " - net: nfc: nci: Add parameter validation for packet data", " - mfd: rz-mtu3: Fix MTU5 NFCR register offset", " - mfd: vexpress-sysreg: Check the return value of devm_gpiochip_add_data()", " - dm: fix queue start/stop imbalance under suspend/load/resume races", " - dm: fix NULL pointer dereference in __dm_suspend()", " - LoongArch: Automatically disable kaslr if boot from kexec_file", " - ksmbd: fix error code overwriting in smb2_get_info_filesystem()", " - ext4: fix checks for orphan inodes", " - mm: hugetlb: avoid soft lockup when mprotect to large memory area", " - nvdimm: ndtest: Return -ENOMEM if devm_kcalloc() fails in ndtest_probe()", " - misc: fastrpc: Fix fastrpc_map_lookup operation", " - misc: fastrpc: fix possible map leak in fastrpc_put_args", " - misc: fastrpc: Skip reference for DMA handles", " - Input: atmel_mxt_ts - allow reset GPIO to sleep", " - Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info", " leak", " - sunrpc: fix null pointer dereference on zero-length checksum", " - remoteproc: pru: Fix potential NULL pointer dereference in", " pru_rproc_set_ctable()", " - pinctrl: check the return value of pinmux_ops::get_function_name()", " - bus: fsl-mc: Check return value of platform_get_resource()", " - net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock", " - usb: typec: tipd: Clear interrupts first", " - arm64: dts: qcom: qcm2290: Disable USB SS bus instances in park mode", " - usb: cdns3: cdnsp-pci: remove redundant pci_disable_device() call", " - Bluetooth: btusb: Add USB ID 2001:332a for D-Link AX9U rev. A1", " - wifi: rtl8xxxu: Don't claim USB ID 07b8:8188", " - netfs: Prevent duplicate unlocking", " - nvmem: layouts: fix automatic module loading", " - uprobes: uprobe_warn should use passed task", " - lsm: CONFIG_LSM can depend on CONFIG_SECURITY", " - vdso: Add struct __kernel_old_timeval forward declaration to gettime.h", " - selftests: vDSO: vdso_test_abi: Correctly skip whole test with missing", " vDSO", " - PM / devfreq: rockchip-dfi: double count on RK3588", " - soc: mediatek: mtk-svs: fix device leaks on mt8183 probe failure", " - soc: mediatek: mtk-svs: fix device leaks on mt8192 probe failure", " - pwm: tiehrpwm: Don't drop runtime PM reference in .free()", " - pwm: tiehrpwm: Make code comment in .free() more useful", " - pwm: tiehrpwm: Fix various off-by-one errors in duty-cycle calculation", " - spi: fix return code when spi device has too many chipselects", " - bpf: Mark kfuncs as __noclone", " - crypto: octeontx2 - Call strscpy() with correct size argument", " - RDMA/mlx5: Better estimate max_qp_wr to reflect WQE count", " - idpf: fix Rx descriptor ready check barrier in splitq", " - wifi: mt76: mt7996: Fix RX packets configuration for primary WED device", " - wifi: mt76: mt7996: Convert mt7996_wed_rro_addr to LE", " - HID: hidraw: tighten ioctl command parsing", " - wifi: ath12k: fix wrong logging ID used for CE", " - coresight: tmc: Move ACPI support from AMBA driver to platform driver", " - coresight: tmc: Support atclk", " - coresight: catu: Move ACPI support from AMBA driver to platform driver", " - coresight: catu: Support atclk", " - PCI: rcar-gen4: Add missing 1ms delay after PWR reset assertion", " - PCI: rcar-gen4: Assure reset occurs before DBI access", " - Bluetooth: ISO: free rx_skb if not consumed", " - PCI: j721e: Fix incorrect error message in probe()", " - Upstream stable to v6.6.111, v6.6.112, v6.12.52, v6.12.53", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40031", " - tee: fix register_shm_helper()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40037", " - fbdev: simplefb: Fix use after free in simplefb_detach_genpds()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40047", " - io_uring/waitid: always prune wait queue entry in io_waitid_wait()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40057", " - ptp: Add a upper bound on max_vclocks", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40058", " - iommu/vt-d: Disallow dirty tracking if incoherent page walk", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40059", " - coresight: Fix incorrect handling for return value of devm_kzalloc", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40155", " - iommu/vt-d: debugfs: Fix legacy mode page table dump logic", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40079", " - riscv, bpf: Sign extend struct ops return values properly", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40000", " - wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40026", " - KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40027", " - net/9p: fix double req put in p9_fd_cancelled", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40109", " - crypto: rng - Ensure set_ent is always present", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-38105", " - ALSA: usb-audio: Kill timer properly at removal", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-40107", " - can: hi311x: fix null pointer dereference when resuming from sleep", " before interface was enabled", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-39995", " - media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in", " probe", "", " * Noble update: upstream stable patchset 2026-01-26 (LP: #2139072) //", " CVE-2025-39994", " - media: tuner: xc5000: Fix use-after-free in xc5000_release", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938)", " - scsi: ufs: mcq: Fix memory allocation checks for SQE and CQE", " - firewire: core: fix overlooked update of subsystem ABI version", " - ALSA: usb-audio: Fix block comments in mixer_quirks", " - ALSA: usb-audio: Drop unnecessary parentheses in mixer_quirks", " - ALSA: usb-audio: Avoid multiple assignments in mixer_quirks", " - ALSA: usb-audio: Simplify NULL comparison in mixer_quirks", " - ALSA: usb-audio: Remove unneeded wmb() in mixer_quirks", " - ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5", " - ALSA: usb-audio: Convert comma to semicolon", " - ALSA: usb-audio: Fix build with CONFIG_INPUT=n", " - usb: core: Add 0x prefix to quirks debug output", " - mmc: sdhci-cadence: add Mobileye eyeQ support", " - i2c: designware: Add quirk for Intel Xe", " - ALSA: usb-audio: Add DSD support for Comtrue USB Audio device", " - ALSA: usb-audio: move mixer_quirks' min_mute into common quirk", " - ALSA: usb-audio: Add mute TLV for playback volumes on more devices", " - IB/mlx5: Fix obj_type mismatch for SRQ event subscriptions", " - mm: add folio_expected_ref_count() for reference count calculation", " - mm/gup: check ref_count instead of lru before migration", " - mm/gup: local lru_add_drain() to avoid lru_add_drain_all()", " - mm: folio_may_be_lru_cached() unless folio_test_large()", " - arm64: dts: imx8mp: Correct thermal sensor index", " - ARM: dts: kirkwood: Fix sound DAI cells for OpenRD clients", " - cpufreq: Initialize cpufreq-based invariance before subsys", " - smb: server: don't use delayed_work for post_recv_credits_work", " - wifi: virt_wifi: Fix page fault on connect", " - can: rcar_can: rcar_can_resume(): fix s2ram with PSCI", " - bpf: Reject bpf_timer for PREEMPT_RT", " - xfrm: xfrm_alloc_spi shouldn't use 0 as SPI", " - ethernet: rvu-af: Remove slash from the driver name", " - Bluetooth: hci_sync: Fix hci_resume_advertising_sync", " - bnxt_en: correct offset handling for IPv6 destination address", " - net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS", " - selftests: fib_nexthops: Fix creation of non-FDB nexthops", " - net: dsa: lantiq_gswip: do also enable or disable cpu port", " - net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to", " port_setup()", " - net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB entries", " added to the CPU port", " - HID: asus: add support for missing PX series fn keys", " - i40e: add mask to apply valid bits for itr_idx", " - i40e: improve VF MAC filters accounting", " - ARM: dts: socfpga: sodia: Fix mdio bus probe and PHY address", " - fbcon: Fix OOB access in font allocation", " - s390/cpum_cf: Fix uninitialized warning after backport of ce971233242b", " - ARM: bcm: Select ARM_GIC_V3 for ARCH_BRCMSTB", " - gpiolib: Extend software-node support to support secondary software-", " nodes", " - drm/ast: Use msleep instead of mdelay for edid read", " - minmax: make generic MIN() and MAX() macros available everywhere", " - minmax: simplify min()/max()/clamp() implementation", " - minmax: don't use max() in situations that want a C constant expression", " - minmax: improve macro expansion and type checking", " - minmax: fix up min3() and max3() too", " - minmax.h: add whitespace around operators and after commas", " - minmax.h: update some comments", " - minmax.h: reduce the #define expansion of min(), max() and clamp()", " - minmax.h: move all the clamp() definitions after the min/max() ones", " - minmax.h: simplify the variants of clamp()", " - minmax.h: remove some #defines that are only expanded once", " - drm/i915/backlight: Return immediately when scale() finds invalid", " parameters", " - ALSA: usb-audio: Fix code alignment in mixer_quirks", " - ALSA: hda/realtek: Add support for ASUS NUC using CS35L41 HDA", " - net: fec: rename struct fec_devinfo fec_imx6x_info -> fec_imx6sx_info", " - net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick", " - net: sfp: add quirk for FLYPRO copper SFP+ module", " - HID: amd_sfh: Add sync across amd sfh work functions", " - platform/x86: lg-laptop: Fix WMAB call in fan_mode_store()", " - crypto: sha256 - fix crash at kexec", " - gcc-plugins: Remove TODO_verify_il for GCC >= 16", " - Upstream stable to v6.6.109, v6.6.110, v6.12.50, v6.12.51", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39991", " - wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39992", " - mm: swap: check for stable address space before operating on the VMA", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40013", " - ASoC: qcom: audioreach: fix potential null pointer dereference", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40016", " - media: uvcvideo: Mark invalid entities with id UVC_INVALID_ENTITY_ID", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39996", " - media: b2c2: Fix use-after-free causing by irq_check_work in", " flexcop_pci_remove", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39998", " - scsi: target: target_core_configfs: Add length check to avoid buffer", " overflow", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40009", " - fs/proc/task_mmu: check p->vec_buf for NULL", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39973", " - i40e: add validation for ring_len param", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-38709", " - loop: Avoid updating block size under exclusive owner", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39967", " - fbcon: fix integer overflow in fbcon_do_set_font", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40006", " - mm/hugetlb: fix folio is still mapped when deleted", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40008", " - kmsan: fix out-of-bounds access to shadow memory", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40010", " - afs: Fix potential null pointer dereference in afs_put_server", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40021", " - tracing: dynevent: Add a missing lockdown check on dynevent", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39968", " - i40e: add max boundary check for VF filters", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39969", " - i40e: fix validation of VF state in get resources", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39970", " - i40e: fix input validation logic for action_meta", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39971", " - i40e: fix idx validation in config queues msg", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39972", " - i40e: fix idx validation in i40e_validate_queue_map", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39977", " - futex: Prevent use-after-free during requeue-PI", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40011", " - drm/gma500: Fix null dereference in hdmi teardown", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39978", " - octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39980", " - nexthop: Forbid FDB status change while nexthop is in a group", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40024", " - vhost: Take a reference on the task in struct vhost_task.", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39982", " - Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-40020", " - can: peak_usb: fix shift-out-of-bounds issue", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39985", " - can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39986", " - can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39987", " - can: hi311x: populate ndo_change_mtu() to prevent buffer overflow", "", " * Noble update: upstream stable patchset 2026-01-23 (LP: #2138938) //", " CVE-2025-39988", " - can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867)", " - ALSA: firewire-motu: drop EPOLLOUT from poll return values as write is", " not supported", " - wifi: mac80211: fix incorrect type for ret", " - pcmcia: omap_cf: Mark driver struct with __refdata to prevent section", " mismatch", " - bonding: set random address only when slaves already exist", " - power: supply: bq27xxx: fix error return in case of no bq27000 hdq", " battery", " - power: supply: bq27xxx: restrict no-battery detection to bq27000", " - LoongArch: Update help info of ARCH_STRICT_ALIGN", " - LoongArch: Align ACPI structures if ARCH_STRICT_ALIGN enabled", " - LoongArch: Check the return value when creating kobj", " - iommu/vt-d: Fix __domain_mapping()'s usage of switch_to_super_page()", " - btrfs: tree-checker: fix the incorrect inode ref size check", " - ASoC: qcom: audioreach: Fix lpaif_type configuration for the I2S", " interface", " - ASoC: qcom: q6apm-lpass-dais: Fix missing set_fmt DAI op for I2S", " - rds: ib: Increment i_fastreg_wrs before bailing out", " - selftests: mptcp: connect: catch IO errors on listen side", " - selftests: mptcp: avoid spurious errors on TCP disconnect", " - ALSA: hda/realtek: Fix mute led for HP Laptop 15-dw4xx", " - io_uring: backport io_should_terminate_tw()", " - io_uring: include dying ring in task_work \"should cancel\" state", " - ASoC: wm8940: Correct PLL rate rounding", " - ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in error", " message", " - drm: bridge: cdns-mhdp8546: Fix missing mutex unlock on error path", " - selftests: mptcp: userspace pm: validate deny-join-id0 flag", " - xhci: dbc: decouple endpoint allocation from initialization", " - xhci: dbc: Fix full DbC transfer ring after several reconnects", " - rtc: pcf2127: fix SPI command byte for PCF2131 backport", " - mptcp: propagate shutdown to subflows when possible", " - minmax: avoid overly complicated constant expressions in VM code", " - minmax: simplify and clarify min_t()/max_t() implementation", " - minmax: add a few more MIN_T/MAX_T users", " - nvme: fix PI insert on write", " - btrfs: fix invalid extref key setup when replaying dentry", " - dpaa2-switch: fix buffer pool seeding for control traffic", " - mptcp: set remote_deny_join_id0 on SYN recv", " - mptcp: tfo: record 'deny join id0' info", " - selftests: mptcp: sockopt: fix error messages", " - net: natsemi: fix `rx_dropped` double accounting on `netif_rx()` failure", " - ice: store max_frame and rx_buf_len only in ice_rx_ring", " - i40e: remove redundant memory barrier when cleaning Tx descs", " - bonding: don't set oif to bond dev when getting NS target destination", " - octeon_ep: fix VF MAC address lifecycle handling", " - net: liquidio: fix overflow in octeon_init_instr_queue()", " - nilfs2: fix CFI failure when accessing /sys/fs/nilfs2/features/*", " - dm-raid: don't set io_min and io_opt for raid1", " - mm: revert \"mm: vmscan.c: fix OOM on swap stress test\"", " - mmc: mvsdio: Fix dma_unmap_sg() nents value", " - KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active", " - ASoC: wm8940: Correct typo in control name", " - ASoC: wm8974: Correct PLL rate rounding", " - ASoC: Intel: catpt: Expose correct bit depth to userspace", " - drm/xe: Fix a NULL vs IS_ERR() in xe_vm_add_compute_exec_queue()", " - smb: client: fix filename matching of deferred files", " - platform/x86: asus-wmi: Fix ROG button mapping, tablet mode on ASUS ROG", " Z13", " - platform/x86: asus-wmi: Re-add extra keys to ignore_key_wlan quirk", " - x86/bugs: Add SRSO_USER_KERNEL_NO support", " - x86/bugs: KVM: Add support for SRSO_MSR_FIX", " - KVM: SVM: Set/clear SRSO's BP_SPEC_REDUCE on 0 <=> 1 VM count", " transitions", " - mptcp: pm: nl: announce deny-join-id0 flag", " - Upstream stable to v6.6.108, v6.12.49", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39932", " - smb: client: let smbd_destroy() call", " disable_work_sync(&info->post_send_credits_work)", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39940", " - dm-stripe: fix a possible integer overflow", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39948", " - ice: fix Rx page leak on multi-buffer frames", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39950", " - net/tcp: Fix a NULL pointer dereference when using TCP-AO with", " TCP_REPAIR", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39961", " - iommu/amd/pgtbl: Fix possible race while increase page table level", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-22106", " - vmxnet3: unregister xdp rxq info in the reset path", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39929", " - smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39931", " - crypto: af_alg - Set merge to zero early in af_alg_sendmsg", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39934", " - drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39937", " - net: rfkill: gpio: Fix crash due to dereferencering uninitialized", " pointer", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39938", " - ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source", " graph failed", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39942", " - ksmbd: smbdirect: verify remaining_data_length respects", " max_fragmented_recv_size", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39943", " - ksmbd: smbdirect: validate data_offset and data_length field of", " smb_direct_data_transfer", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39944", " - octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39945", " - cnic: Fix use-after-free bugs in cnic_delete_task", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39955", " - tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39947", " - net/mlx5e: Harden uplink netdev access against device unbind", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39949", " - qed: Don't collect too many protection override GRC elements", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39951", " - um: virtio_uml: Fix use-after-free after put_device in probe", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39953", " - cgroup: split cgroup_destroy_wq into 3 workqueues", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39957", " - wifi: mac80211: increase scan_ies_len for S1G", "", " * Noble update: upstream stable patchset 2026-01-22 (LP: #2138867) //", " CVE-2025-39952", " - wifi: wilc1000: avoid buffer overflow in WID string configuration", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681)", " - mm: introduce and use {pgd,p4d}_populate_kernel()", " - kasan: fix GCC mem-intrinsic prefix with sw tags", " - ima: limit the number of ToMToU integrity violations", " - flexfiles/pNFS: fix NULL checks on result of", " ff_layout_choose_ds_for_read", " - SUNRPC: call xs_sock_process_cmsg for all cmsg", " - NFSv4: Don't clear capabilities that won't be reset", " - NFSv4: Clear the NFS_CAP_FS_LOCATIONS flag if it is not set", " - NFSv4: Clear the NFS_CAP_XATTR flag if not supported by the server", " - tracing: Fix tracing_marker may trigger page fault during", " preempt_disable", " - ftrace/samples: Fix function size computation", " - fs/nfs/io: make nfs_start_io_*() killable", " - NFS: Serialise O_DIRECT i/o and truncate()", " - NFSv4.2: Serialise O_DIRECT i/o and fallocate()", " - NFSv4.2: Serialise O_DIRECT i/o and clone range", " - NFSv4.2: Serialise O_DIRECT i/o and copy range", " - NFSv4/flexfiles: Fix layout merge mirror check.", " - s390/cpum_cf: Deny all sampling events by counter PMU", " - proc: fix type confusion in pde_set_flags()", " - EDAC/altera: Delete an inappropriate dma_free_coherent() call", " - compiler-clang.h: define __SANITIZE_*__ macros only when undefined", " - net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO runtime PM", " wakeups", " - mtd: rawnand: stm32_fmc2: fix ECC overwrite", " - fuse: check if copy_file_range() returns larger than requested size", " - fuse: prevent overflow in copy_file_range return value", " - mm/damon/core: set quota->charged_from to jiffies at first charge window", " - drm/mediatek: fix potential OF node use-after-free", " - drm/amdgpu/vcn: Allow limiting ctx to instance 0 for AV1 at any time", " - drm/amdgpu/vcn4: Fix IB parsing with multiple engine info packages", " - mtd: nand: raw: atmel: Fix comment in timings preparation", " - mtd: nand: raw: atmel: Respect tAR, tCLR in read setup timing", " - btrfs: use readahead_expand() on compressed extents", " - btrfs: fix corruption reading compressed range when block size is", " smaller than page size", " - mm/khugepaged: fix the address passed to notifier on testing young", " - Input: iqs7222 - avoid enabling unused interrupts", " - Input: i8042 - add TUXEDO InfinityBook Pro Gen10 AMD to i8042 quirk", " table", " - tty: hvc_console: Call hvc_kick in hvc_write unconditionally", " - serial: sc16is7xx: fix bug in flow control levels init", " - dt-bindings: serial: brcm,bcm7271-uart: Constrain clocks", " - USB: serial: option: add Telit Cinterion FN990A w/audio compositions", " - USB: serial: option: add Telit Cinterion LE910C4-WWX new compositions", " - net: bridge: Bounce invalid boolopts", " - tunnels: reset the GSO metadata before reusing the skb", " - docs: networking: can: change bcm_msg_head frames member to support", " flexible array", " - igb: fix link test skipping when interface is admin down", " - can: j1939: j1939_sk_bind(): call j1939_priv_put() immediately when", " j1939_local_ecu_get() failed", " - can: j1939: j1939_local_ecu_get(): undo increment when", " j1939_local_ecu_get() fails", " - net: hsr: Add VLAN CTAG filter support", " - hsr: use rtnl lock when iterating over ports", " - hsr: use hsr_for_each_port_rtnl in hsr_port_get_hsr", " - dmaengine: idxd: Remove improper idxd_free", " - dmaengine: idxd: Fix refcount underflow on module unload", " - dmaengine: idxd: Fix double free in idxd_setup_wqs()", " - regulator: sy7636a: fix lifecycle of power good gpio", " - hrtimer: Remove unused function", " - hrtimer: Rename __hrtimer_hres_active() to hrtimer_hres_active()", " - hrtimers: Unconditionally update target CPU base after offline timer", " migration", " - RISC-V: Remove unnecessary include from compat.h", " - xhci: fix memory leak regression when freeing xhci vdev devices depth", " first", " - USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels", " - usb: gadget: midi2: Fix missing UMP group attributes initialization", " - usb: gadget: midi2: Fix MIDI2 IN EP max packet size", " - dmaengine: dw: dmamux: Fix device reference leak in", " rzn1_dmamux_route_allocate", " - phy: tegra: xusb: fix device and OF node leak at probe", " - phy: ti-pipe3: fix device leak at unbind", " - net: mdiobus: release reset_gpio in mdiobus_unregister_device()", " - drm/amdgpu: fix a memory leak in fence cleanup when unloading", " - drm/i915/power: fix size for for_each_set_bit() in abox iteration", " - nvme-pci: skip nvme_write_sq_db on empty rqlist", " - ext4: introduce linear search for dentries", " - drm/i915/pmu: Fix zero delta busyness issue", " - drm/amd/display: Fix error pointers in amdgpu_dm_crtc_mem_type_changed", " - Revert \"drm/amd/display: Optimize cursor position updates\"", " - ALSA: hda/realtek: Fix built-in mic assignment on ASUS VivoBook X515UA", " - drm/amdgpu: Add back JPEG to video caps for carrizo and newer", " - trace/fgraph: Fix error handling", " - NFS: nfs_invalidate_folio() must observe the offset and size arguments", " - s390/pai: Deny all events not handled by this PMU", " - btrfs: fix squota compressed stats leak", " - netlink: specs: mptcp: add missing 'server-side' attr", " - netlink: specs: mptcp: clearly mention attributes", " - netlink: specs: mptcp: replace underscores with dashes in names", " - netlink: specs: mptcp: fix if-idx attribute type", " - ceph: fix race condition where r_parent becomes stale before sending", " message", " - mtd: spinand: winbond: Fix oob_layout for W25N01JW", " - Revert \"net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO", " runtime PM wakeups\"", " - drm/amd/display: use udelay rather than fsleep", " - netfilter: nft_set_rbtree: continue traversal if element is inactive", " - netfilter: nf_tables: place base_seq in struct net", " - netfilter: nf_tables: make nft_set_do_lookup available unconditionally", " - netfilter: nf_tables: restart set lookup on base_seq change", " - phy: qualcomm: phy-qcom-eusb2-repeater: fix override properties", " - phy: ti: omap-usb2: fix device leak at unbind", " - Upstream stable to v6.6.107, v6.12.48", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39927", " - ceph: fix race condition validating r_parent before applying state", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39923", " - dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39869", " - dmaengine: ti: edma: Fix memory allocation size for queue_priority_map", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39873", " - can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted", " SKB", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39911", " - i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39876", " - net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39881", " - kernfs: Fix UAF in polling when open file is released", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39909", " - mm/damon/lru_sort: avoid divide-by-zero in", " damon_lru_sort_apply_parameters()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39916", " - mm/damon/reclaim: avoid divide-by-zero in", " damon_reclaim_apply_parameters()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39877", " - mm/damon/sysfs: fix use-after-free in state_show()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39880", " - libceph: fix invalid accesses to ceph_connection_v1_info", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39883", " - mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison", " memory", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39907", " - mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39885", " - ocfs2: fix recursive semaphore deadlock in fiemap call", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39913", " - tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to", " allocate psock->cork.", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39886", " - bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-39914", " - tracing: Silence warning when chunk allocation fails in trace_pid_write", "", " * Noble update: upstream stable patchset 2026-01-20 (LP: #2138681) //", " CVE-2025-23143", " - net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502)", " - bpf: Add cookie object to bpf maps", " - bpf: Move cgroup iterator helpers to bpf.h", " - btrfs: fix race between logging inode and checking if it was logged", " before", " - btrfs: fix race between setting last_dir_index_offset and inode logging", " - btrfs: avoid load/store tearing races when checking if an inode was", " logged", " - LoongArch: Save LBT before FPU in setup_sigcontext()", " - cdc_ncm: Flag Intel OEM version of Fibocom L850-GL as WWAN", " - drm/amd/display: Don't warn when missing DCE encoder caps", " - cpupower: Fix a bug where the -t option of the set subcommand was not", " working.", " - Bluetooth: hci_sync: Avoid adding default advertising on startup", " - arm64: dts: rockchip: Add vcc-supply to SPI flash on rk3399-pinebook-pro", " - tee: optee: ffa: fix a typo of \"optee_ffa_api_is_compatible\"", " - arm64: dts: imx8mp: Fix missing microSD slot vqmmc on DH electronics", " i.MX8M Plus DHCOM", " - arm64: dts: imx8mp: Fix missing microSD slot vqmmc on Data Modul i.MX8M", " Plus eDM SBC", " - netfilter: conntrack: helper: Replace -EEXIST by -EBUSY", " - xirc2ps_cs: fix register access when enabling FullDuplex", " - mISDN: Fix memory leak in dsp_hwec_enable()", " - icmp: fix icmp_ndo_send address translation for reply direction", " - net: macb: Fix tx_ptr_lock locking", " - macsec: read MACSEC_SA_ATTR_PN with nla_get_uint", " - wifi: ath11k: rename ath11k_start_vdev_delay()", " - wifi: ath11k: avoid forward declaration of ath11k_mac_start_vdev_delay()", " - wifi: ath11k: fix group data packet drops during rekey", " - net: ethernet: mtk_eth_soc: fix tx vlan tag for llc packets", " - wifi: cw1200: cap SSID length in cw1200_do_join()", " - wifi: libertas: cap SSID len in lbs_associate()", " - net: thunder_bgx: add a missing of_node_put", " - net: thunder_bgx: decrement cleanup index before use", " - ipv4: Fix NULL vs error pointer check in inet_blackhole_dev_init()", " - net/smc: Remove validation of reserved bits in CLC Decline message", " - mctp: return -ENOPROTOOPT for unknown getsockopt options", " - net: atm: fix memory leak in atm_register_sysfs when device_register", " fail", " - selftest: net: Fix weird setsockopt() in bind_bhash.c.", " - phy: mscc: Stop taking ts_lock for tx_queue and use its own lock", " - ALSA: usb-audio: Add mute TLV for playback volumes on some devices", " - ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids()", " - arm64: ftrace: fix unreachable PLT for ftrace_caller in init_module with", " CONFIG_DYNAMIC_FTRACE", " - proc: fix missing pde_set_flags() for net proc files", " - soc: qcom: mdt_loader: Deal with zero e_shentsize", " - wifi: mt76: mt7996: Initialize hdr before passing to skb_put_data()", " - drm/amdgpu: drop hw access in non-DC audio fini", " - platform/x86/amd/pmc: Add TUXEDO IB Pro Gen10 AMD to spurious 8042", " quirks list", " - e1000e: fix heap overflow in e1000_set_eeprom", " - net: pcs: rzn1-miic: Correct MODCTRL register offset", " - cpufreq: intel_pstate: Fold intel_pstate_max_within_limits() into caller", " - cpufreq: intel_pstate: Do not update global.turbo_disabled after", " initialization", " - cpufreq: intel_pstate: Unchecked MSR aceess in legacy mode", " - thermal/drivers/mediatek/lvts: Disable low offset IRQ for minimum", " threshold", " - PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads", " - dmaengine: mediatek: Fix a possible deadlock error in", " mtk_cqdma_tx_status()", " - ALSA: hda/hdmi: Add pin fix for another HP EliteDesk 800 G4 model", " - ALSA: hda/realtek: Fix headset mic for TongFang X6[AF]R5xxY", " - pcmcia: omap: Add missing check for platform_get_resource", " - hwmon: mlxreg-fan: Prevent fans from getting stuck at 0 RPM", " - spi: spi-fsl-lpspi: Fix transmissions when using CONT", " - spi: spi-fsl-lpspi: Set correct chip-select polarity bit", " - spi: spi-fsl-lpspi: Reset FIFO and disable module on transfer abort", " - spi: spi-fsl-lpspi: Clear status register after disabling the module", " - drm/bridge: ti-sn65dsi86: fix REFCLK setting", " - perf bpf-event: Fix use-after-free in synthesis", " - drm/amdgpu: Replace DRM_* with dev_* in amdgpu_psp.c", " - drm/amd/amdgpu: Fix missing error return on kzalloc failure", " - tools: gpio: rm .*.cmd on make clean", " - tools: gpio: remove the include directory on make clean", " - riscv: use lw when reading int cpu in asm_per_cpu", " - cpufreq: intel_pstate: Rearrange show_no_turbo() and store_no_turbo()", " - cpufreq: intel_pstate: Read global.no_turbo under READ_ONCE()", " - cpufreq: intel_pstate: Check turbo_is_disabled() in store_no_turbo()", " - dmaengine: mediatek: Fix a flag reuse error in mtk_cqdma_tx_status()", " - bpf: Move bpf map owner out of common struct", " - btrfs: zoned: skip ZONE FINISH of conventional zones", " - arm64: dts: imx8mp-tqma8mpql: fix LDO5 power off", " - HID: simplify snto32()", " - HID: stop exporting hid_snto32()", " - net: usb: qmi_wwan: fix Telit Cinterion FN990A name", " - net: usb: qmi_wwan: fix Telit Cinterion FE990A name", " - net: usb: qmi_wwan: add Telit Cinterion FN990A w/audio composition", " - LoongArch: vDSO: Remove --hash-style=sysv", " - LoongArch: vDSO: Remove -nostdlib complier flag", " - mmc: sdhci-of-arasan: Support for emmc hardware reset", " - mmc: sdhci-of-arasan: Ensure CD logic stabilization before power-up", " - bnxt_en: fix incorrect page count in RX aggr ring log", " - net: mctp: mctp_fraq_queue should take ownership of passed skb", " - idpf: set mac type when adding and removing MAC filters", " - net: skb: add pskb_network_may_pull_reason() helper", " - net: tunnel: add pskb_inet_may_pull_reason() helper", " - net: vxlan: add skb drop reasons to vxlan_rcv()", " - net: vxlan: make vxlan_snoop() return drop reasons", " - net: vxlan: make vxlan_set_mac() return drop reasons", " - net: vxlan: use kfree_skb_reason() in vxlan_xmit()", " - net: vxlan: use kfree_skb_reason() in vxlan_mdb_xmit()", " - net: vxlan: rename SKB_DROP_REASON_VXLAN_NO_REMOTE", " - vxlan: Refresh FDB 'updated' time upon 'NTF_USE'", " - vxlan: Avoid unnecessary updates to FDB 'used' time", " - vxlan: Add RCU read-side critical sections in the Tx path", " - vxlan: Rename FDB Tx lookup function", " - mm: fix possible deadlock in kmemleak", " - drm/amd/display: Clear the CUR_ENABLE register on DCN314 w/out DPP PG", " - net: dsa: add hook to determine whether EEE is supported", " - net: dsa: provide implementation of .support_eee()", " - md/raid1,raid10: don't handle IO error for REQ_RAHEAD and REQ_NOWAIT", " - md/raid1,raid10: strip REQ_NOWAIT from member bios", " - ext4: define ext4_journal_destroy wrapper", " - wifi: ath11k: update channel list in worker when wait flag is set", " - nouveau: fix disabling the nonstall irq due to storm code", " - kunit: kasan_test: disable fortify string checker on kasan_strings()", " test", " - platform/x86: asus-wmi: Remove extra keys from ignore_key_wlan quirk", " - perf bpf-utils: Constify bpil_array_desc", " - perf bpf-utils: Harden get_bpf_prog_info_linear", " - md/raid1: fix data lost for writemostly rdev", " - Upstream stable to v6.6.105, v6.6.106, v6.12.46, v6.12.47", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-22124", " - md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-22103", " - net: fix NULL pointer dereference in l3mdev_l3_rcv", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-23133", " - wifi: ath11k: update channel list in reg notifier instead reg worker", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-22113", " - ext4: avoid journaling sb update on error if journal is destroying", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-22125", " - md/raid1,raid10: don't ignore IO flags", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39899", " - mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39897", " - net: xilinx: axienet: Add error handling for RX metadata pointer", " retrieval", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39850", " - vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39851", " - vxlan: Fix NPD when refreshing an FDB entry with a nexthop object", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39852", " - net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39901", " - i40e: remove read access to debugfs files", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39854", " - ice: fix NULL access of tx->in_use in ice_ll_ts_intr", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-38556", " - HID: core: Harden s32ton() against conversion to 0 bits", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-38502", " - bpf: Fix oob access in cgroup local storage", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39843", " - mm: slub: avoid wake up kswapd in set_track_prepare", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39920", " - pcmcia: Add error handling for add_interval() in do_validate_mem()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39902", " - mm/slub: avoid accessing metadata when pointer is invalid in", " object_err()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39838", " - cifs: prevent NULL pointer dereference in UTF16 conversion", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39839", " - batman-adv: fix OOB read/write in network-coding decode", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39841", " - scsi: lpfc: Fix buffer free/clear order in deferred receive path", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39891", " - wifi: mwifiex: Initialize the chan_stats array to zero", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39842", " - ocfs2: prevent release journal inode after journal shutdown", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39895", " - sched: Fix sched_numa_find_nth_cpu() if mask offline", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39844", " - mm: move page table sync declarations to linux/pgtable.h", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39845", " - x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and", " arch_sync_kernel_mappings()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39846", " - pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39847", " - ppp: fix memory leak in pad_compress_skb", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39848", " - ax25: properly unshare skbs in ax25_kiss_rcv()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39849", " - wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39853", " - i40e: Fix potential invalid access when MAC list is empty", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39857", " - net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39860", " - Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39861", " - Bluetooth: vhci: Prevent use-after-free by removing debugfs files early", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39894", " - netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in()", " after confirm", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39863", " - wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info", " work", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39864", " - wifi: cfg80211: fix use-after-free in cmp_bss()", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39865", " - tee: fix NULL pointer dereference in tee_shm_put", "", " * Noble update: upstream stable patchset 2026-01-16 (LP: #2138502) //", " CVE-2025-39866", " - fs: writeback: fix use-after-free in __mark_inode_dirty()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664)", " - of: dynamic: Fix memleak when of_pci_add_properties() failed", " - pinctrl: STMFX: add missing HAS_IOMEM dependency", " - mips: dts: lantiq: danube: add missing burst length property", " - mips: lantiq: xway: sysctrl: rename the etop node", " - of: Add a helper to free property struct", " - of: dynamic: Fix use after free in of_changeset_add_prop_helper()", " - scsi: core: sysfs: Correct sysfs attributes access rights", " - smb: client: fix race with concurrent opens in unlink(2)", " - ASoC: codecs: tx-macro: correct tx_macro_component_drv name", " - erofs: fix atomic context detection when !CONFIG_DEBUG_LOCK_ALLOC", " - ACPI: EC: Add device to acpi_ec_no_wakeup[] qurik list", " - nfs: fold nfs_page_group_lock_subrequests into", " nfs_lock_and_join_requests", " - vhost/net: Protect ubufs with rcu read lock in vhost_net_ubuf_put()", " - net: ipv4: fix regression in local-broadcast routes", " - drm/msm: Defer fd_install in SUBMIT ioctl", " - powerpc/kvm: Fix ifdef to remove build warning", " - HID: input: rename hidinput_set_battery_charge_status()", " - HID: input: report battery status changes immediately", " - Bluetooth: hci_event: Treat UNKNOWN_CONN_ID on disconnect as success", " - Bluetooth: hci_event: Mark connection as closed during suspend", " disconnect", " - Bluetooth: hci_event: Detect if HCI_EV_NUM_COMP_PKTS is unbalanced", " - Bluetooth: hci_sync: fix set_local_name race condition", " - drm/nouveau: remove unused increment in gm200_flcn_pio_imem_wr", " - drm/nouveau: remove unused memory target test", " - ice: fix incorrect counter for buffer allocation failures", " - dt-bindings: display/msm: qcom,mdp5: drop lut clock", " - net: dlink: fix multicast stats being counted incorrectly", " - phy: mscc: Fix when PTP clock is register and unregister", " - net/mlx5: Reload auxiliary drivers on fw_activate", " - net/mlx5: Add device cap for supporting hot reset in sync reset flow", " - net/mlx5: Add support for sync reset using hot reset", " - net/mlx5: Nack sync reset when SFs are present", " - net/mlx5e: Set local Xoff after FW update", " - net: stmmac: xgmac: Do not enable RX FIFO Overflow interrupts", " - net: stmmac: Rename phylink_get_caps() callback to update_caps()", " - net: stmmac: xgmac: Correct supported speed modes", " - net: stmmac: Set CIC bit only for TX queues with COE", " - net: rose: split remove and free operations in rose_remove_neigh()", " - x86/microcode/AMD: Handle the case of no BIOS microcode", " - HID: quirks: add support for Legion Go dual dinput modes", " - HID: logitech: Add ids for G PRO 2 LIGHTSPEED", " - HID: wacom: Add a new Art Pen 2", " - dma/pool: Ensure DMA_DIRECT_REMAP allocations are decrypted", " - net: usb: qmi_wwan: add Telit Cinterion LE910C4-WWX new compositions", " - smb3 client: fix return code mapping of remap_file_range", " - drm/nouveau/disp: Always accept linear modifier", " - net: rose: fix a typo in rose_clear_routes()", " - perf symbol-minimal: Fix ehdr reading in filename__read_build_id", " - vhost: Fix ioctl # for VHOST_[GS]ET_FORK_FROM_OWNER", " - drm/msm/kms: move snapshot init earlier in KMS init", " - drm/mediatek: Add error handling for old state CRTC in atomic_disable", " - drm/xe/xe_sync: avoid race during ufence signaling", " - drm/xe: Don't trigger rebind on initial dma-buf validation", " - bnxt_en: Adjust TX rings if reservation is less than requested", " - hv_netvsc: Link queues to NAPIs", " - net: hv_netvsc: fix loss of early receive events from host during", " channel open.", " - net: macb: Disable clocks once", " - drm/nouveau: fix error path in nvkm_gsp_fwsec_v2", " - drm/mediatek: Fix device/node reference count leaks in", " mtk_drm_get_all_drm_priv", " - drm/amd/amdgpu: disable hwmon power1_cap* for gfx 11.0.3 on vf mode", " - PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value", " - PCI: Rename PCIE_RESET_CONFIG_DEVICE_WAIT_MS to", " PCIE_RESET_CONFIG_WAIT_MS", " - PCI: dwc: Rename 'dw_pcie::link_gen' to 'dw_pcie::max_link_speed'", " - PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link up", " - thermal/drivers/mediatek/lvts_thermal: Change lvts commands array to", " static const", " - thermal/drivers/mediatek/lvts_thermal: Add lvts commands and their sizes", " to driver data", " - thermal/drivers/mediatek/lvts_thermal: Add mt7988 lvts commands", " - Upstream stable to v6.6.104, v6.12.45", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39811", " - drm/xe/vm: Clear the scratch_pt pointer on error", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39815", " - RISC-V: KVM: fix stack overrun when loading vlenb", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39810", " - bnxt_en: Fix memory corruption when FW resources change during ifdown", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39836", " - efi: stmm: Fix incorrect buffer allocation method", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39805", " - net: macb: fix unregister_netdev call order in macb_remove()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39829", " - trace/fgraph: Fix the warning caused by missing unregister notifier", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39835", " - xfs: do not propagate ENODATA disk errors into xattr code", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39819", " - fs/smb: Fix inconsistent refcnt update", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39808", " - HID: hid-ntrig: fix unable to handle page fault in", " ntrig_report_version()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39806", " - HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39824", " - HID: asus: fix UAF via HID_CLAIMED_INPUT validation", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39823", " - KVM: x86: use array_index_nospec with indices that come from guest", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39817", " - efivarfs: Fix slab-out-of-bounds in efivarfs_d_compare", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39812", " - sctp: initialize more fields in sctp_v6_from_sk()", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39827", " - net: rose: include node references in rose_neigh refcount", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39826", " - net: rose: convert 'use' field to refcount_t", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39832", " - net/mlx5: Fix lockdep assertion on sync reset unload event", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39828", " - atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39697", " - NFS: Fix a race when updating an existing write", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39825", " - smb: client: fix race with concurrent opens in rename(2)", "", " * Noble update: upstream stable patchset 2026-01-07 (LP: #2137664) //", " CVE-2025-39813", " - ftrace: Fix potential warning in trace_printk_seq during ftrace_dump", "", " * CVE-2025-37899", " - ksmbd: fix use-after-free in session logoff", "", " * CVE-2025-22037", " - ksmbd: mark SMB2_SESSION_EXPIRED to session when destroying previous", " session", " - ksmbd: fix race condition between destroy_previous_session() and smb2", " operations()", " - ksmbd: fix null pointer dereference in alloc_preauth_hash()", "" ], "package": "linux", "version": "6.8.0-103.103", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141411, 1786013, 2141314, 2127764, 2137613, 2138120, 2136958, 2130240, 2067642, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139633, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139624, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139460, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139282, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139267, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139158, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2139072, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138938, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138867, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138681, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2138502, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664, 2137664 ], "author": "Edoardo Canepa ", "date": "Tue, 10 Feb 2026 12:14:34 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "to_version": { "source_package_name": "linux-meta-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1975592 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.17.0-19.19.1~24.04.1", "" ], "package": "linux-meta-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:38:07 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.17.0-16.16.1~24.04.1", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/dkms-versions -- resync from main package", "", " * Enable Nezha board (LP: #1975592)", " - [Packaging] Add allwinner transitionals", "" ], "package": "linux-meta-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013, 1975592 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:56:56 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "mount", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "nftables", "from_version": { "source_package_name": "nftables", "source_package_version": "1.0.9-1build1", "version": "1.0.9-1build1" }, "to_version": { "source_package_name": "nftables", "source_package_version": "1.0.9-1ubuntu0.1", "version": "1.0.9-1ubuntu0.1" }, "cves": [], "launchpad_bugs_fixed": [ 2142552 ], "changes": [ { "cves": [], "log": [ "", " * netlink: fix crash when ops doesn't support udata (LP: #2142552)", "" ], "package": "nftables", "version": "1.0.9-1ubuntu0.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2142552 ], "author": "Dimitri John Ledkov ", "date": "Tue, 24 Feb 2026 08:16:27 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-client", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.14", "version": "1:9.6p1-3ubuntu13.14" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.15", "version": "1:9.6p1-3ubuntu13.15" }, "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: GSSAPI Key Exchange issue", " - debian/patches/gssapi.patch: replace incorrect use of", " sshpkt_disconnect() with ssh_packet_disconnect() and properly", " initialize some vars.", " - CVE-2026-3497", " * SECURITY UPDATE: Untrusted control characters in usernames", " - debian/patches/CVE-2025-61984.patch: refuse usernames that include", " control characters in ssh.c.", " - CVE-2025-61984", " * SECURITY UPDATE: Code execution in ProxyCommand via NULL character", " - debian/patches/CVE-2025-61985.patch: don't allow \\0 characters in", " url-encoded strings in misc.c.", " - CVE-2025-61985", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.15", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 04 Mar 2026 12:55:04 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.14", "version": "1:9.6p1-3ubuntu13.14" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.15", "version": "1:9.6p1-3ubuntu13.15" }, "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: GSSAPI Key Exchange issue", " - debian/patches/gssapi.patch: replace incorrect use of", " sshpkt_disconnect() with ssh_packet_disconnect() and properly", " initialize some vars.", " - CVE-2026-3497", " * SECURITY UPDATE: Untrusted control characters in usernames", " - debian/patches/CVE-2025-61984.patch: refuse usernames that include", " control characters in ssh.c.", " - CVE-2025-61984", " * SECURITY UPDATE: Code execution in ProxyCommand via NULL character", " - debian/patches/CVE-2025-61985.patch: don't allow \\0 characters in", " url-encoded strings in misc.c.", " - CVE-2025-61985", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.15", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 04 Mar 2026 12:55:04 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-sftp-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.14", "version": "1:9.6p1-3ubuntu13.14" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.15", "version": "1:9.6p1-3ubuntu13.15" }, "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3497", "url": "https://ubuntu.com/security/CVE-2026-3497", "cve_description": "Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.", "cve_priority": "medium", "cve_public_date": "2026-03-12 19:16:00 UTC" }, { "cve": "CVE-2025-61984", "url": "https://ubuntu.com/security/CVE-2025-61984", "cve_description": "ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" }, { "cve": "CVE-2025-61985", "url": "https://ubuntu.com/security/CVE-2025-61985", "cve_description": "ssh in OpenSSH before 10.1 allows the '\\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.", "cve_priority": "low", "cve_public_date": "2025-10-06 19:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: GSSAPI Key Exchange issue", " - debian/patches/gssapi.patch: replace incorrect use of", " sshpkt_disconnect() with ssh_packet_disconnect() and properly", " initialize some vars.", " - CVE-2026-3497", " * SECURITY UPDATE: Untrusted control characters in usernames", " - debian/patches/CVE-2025-61984.patch: refuse usernames that include", " control characters in ssh.c.", " - CVE-2025-61984", " * SECURITY UPDATE: Code execution in ProxyCommand via NULL character", " - debian/patches/CVE-2025-61985.patch: don't allow \\0 characters in", " url-encoded strings in misc.c.", " - CVE-2025-61985", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.15", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 04 Mar 2026 12:55:04 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-cryptography", "from_version": { "source_package_name": "python-cryptography", "source_package_version": "41.0.7-4ubuntu0.1", "version": "41.0.7-4ubuntu0.1" }, "to_version": { "source_package_name": "python-cryptography", "source_package_version": "41.0.7-4ubuntu0.4", "version": "41.0.7-4ubuntu0.4" }, "cves": [ { "cve": "CVE-2026-26007", "url": "https://ubuntu.com/security/CVE-2026-26007", "cve_description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "cve_priority": "medium", "cve_public_date": "2026-02-10 22:17:00 UTC" }, { "cve": "CVE-2026-26007", "url": "https://ubuntu.com/security/CVE-2026-26007", "cve_description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "cve_priority": "medium", "cve_public_date": "2026-02-10 22:17:00 UTC" } ], "launchpad_bugs_fixed": [ 2144373 ], "changes": [ { "cves": [ { "cve": "CVE-2026-26007", "url": "https://ubuntu.com/security/CVE-2026-26007", "cve_description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "cve_priority": "medium", "cve_public_date": "2026-02-10 22:17:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: ecc support regression (LP: #2144373)", " - debian/patches/CVE-2026-26007.patch: updated to remove problematic", " deprecation warning code which is causing a regression with ansible.", "" ], "package": "python-cryptography", "version": "41.0.7-4ubuntu0.4", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2144373 ], "author": "Marc Deslauriers ", "date": "Sat, 14 Mar 2026 08:18:05 -0400" }, { "cves": [ { "cve": "CVE-2026-26007", "url": "https://ubuntu.com/security/CVE-2026-26007", "cve_description": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "cve_priority": "medium", "cve_public_date": "2026-02-10 22:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Subgroup Attack Due to Missing Subgroup Validation for", " SECT Curves", " - debian/patches/CVE-2026-26007.patch: EC check key on cofactor > 1 in", " src/cryptography/hazmat/primitives/asymmetric/ec.py,", " src/cryptography/utils.py, tests/hazmat/primitives/test_ec.py,", " src/_cffi_src/openssl/ec.py,", " src/cryptography/hazmat/backends/openssl/ec.py.", " - CVE-2026-26007", "" ], "package": "python-cryptography", "version": "41.0.7-4ubuntu0.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 20 Feb 2026 09:45:35 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.12", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.12", "version": "3.12.3-1ubuntu0.12" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.12", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:45:18 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3.12-minimal", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.11", "version": "3.12.3-1ubuntu0.11" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.3-1ubuntu0.12", "version": "3.12.3-1ubuntu0.12" }, "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-15366", "url": "https://ubuntu.com/security/CVE-2025-15366", "cve_description": "The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2025-15367", "url": "https://ubuntu.com/security/CVE-2025-15367", "cve_description": "The poplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" }, { "cve": "CVE-2026-0865", "url": "https://ubuntu.com/security/CVE-2026-0865", "cve_description": "User-controlled header names and values containing newlines can allow injecting HTTP headers.", "cve_priority": "medium", "cve_public_date": "2026-01-20 22:15:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: Revert patch for CVE-2025-15366", " - debian/patches/CVE-2025-15366.patch: Reverted. Patch breaks RFC", " 9051 IMAP conformance and introduces behavior regressions avoided", " by upstream.", " - CVE-2025-15366", " * SECURITY REGRESSION: Revert patch for CVE-2025-15367", " - debian/patches/CVE-2025-15367.patch: Reverted to prevent behavior", " regressions, aligning with upstream backporting decisions.", " - CVE-2025-15367", " * SECURITY REGRESSION: Allow HTAB in wsgiref header values", " - debian/patches/CVE-2026-0865-2.patch: Permit HTAB in header values", " (excluding names) in Lib/wsgiref/headers.py, add test coverage.", " - CVE-2026-0865", "" ], "package": "python3.12", "version": "3.12.3-1ubuntu0.12", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Vyom Yadav ", "date": "Tue, 03 Mar 2026 17:45:18 +0530" } ], "notes": null, "is_version_downgrade": false }, { "name": "snapd", "from_version": { "source_package_name": "snapd", "source_package_version": "2.73+ubuntu24.04", "version": "2.73+ubuntu24.04" }, "to_version": { "source_package_name": "snapd", "source_package_version": "2.73+ubuntu24.04.2", "version": "2.73+ubuntu24.04.2" }, "cves": [ { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd in Ubuntu on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is enabled to automatically clean up this directory.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:00:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd in Ubuntu on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is enabled to automatically clean up this directory.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd in Ubuntu on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is enabled to automatically clean up this directory.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:00:00 UTC" } ], "log": [ "", " * SECURITY REGRESSION: typo in snapd.conf", " - data/systemd-tmpfiles/snapd.conf: Fix typo in config file.", " - CVE-2026-3888", "" ], "package": "snapd", "version": "2.73+ubuntu24.04.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Tue, 17 Mar 2026 20:23:18 +0100" }, { "cves": [ { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd in Ubuntu on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is enabled to automatically clean up this directory.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Local privilege escalation", " - debian/patches/CVE-2026-3888.patch: more precise prune pattern for", " tmpfiles.", " - CVE-2026-3888", "" ], "package": "snapd", "version": "2.73+ubuntu24.04.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Eduardo Barretto ", "date": "Thu, 12 Mar 2026 12:27:32 +0100" } ], "notes": null, "is_version_downgrade": false }, { "name": "sosreport", "from_version": { "source_package_name": "sosreport", "source_package_version": "4.9.2-0ubuntu0~24.04.1", "version": "4.9.2-0ubuntu0~24.04.1" }, "to_version": { "source_package_name": "sosreport", "source_package_version": "4.10.2-0ubuntu0~24.04.1", "version": "4.10.2-0ubuntu0~24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2136302 ], "changes": [ { "cves": [], "log": [ "", " * New 4.10.2 upstream release. (LP: #2136302)", "", " * For more details, full release note is available here:", " - https://github.com/sosreport/sos/releases/tag/4.10.2", "", " * d/control: Add gpg to Recommends so that we are able encrypt and decrypt", " sos report archives", "", " * d/copyright: sync with Debian", "", " * Former patches, now fixed:", " - d/p/0002-component-Grab-tmpdir-from-policy.patch", "", " * Remaining patches:", " - d/p/0001-debian-change-tmp-dir-location.patch", "" ], "package": "sosreport", "version": "4.10.2-0ubuntu0~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2136302 ], "author": "Arif Ali ", "date": "Tue, 16 Dec 2025 18:05:32 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "sudo", "from_version": { "source_package_name": "sudo", "source_package_version": "1.9.15p5-3ubuntu5.24.04.1", "version": "1.9.15p5-3ubuntu5.24.04.1" }, "to_version": { "source_package_name": "sudo", "source_package_version": "1.9.15p5-3ubuntu5.24.04.2", "version": "1.9.15p5-3ubuntu5.24.04.2" }, "cves": [], "launchpad_bugs_fixed": [ 2143042 ], "changes": [ { "cves": [], "log": [ "", " * SECURITY UPDATE: exec_mailer gid issue (LP: #2143042)", " - debian/patches/lp2143042.patch: set group as well as uid when running", " the mailer and make a setuid(), setgid() or setgroups() failure fatal", " in include/sudo_eventlog.h, lib/eventlog/eventlog.c,", " lib/eventlog/eventlog_conf.c, plugins/sudoers/logging.c,", " plugins/sudoers/policy.c.", " - No CVE number", "" ], "package": "sudo", "version": "1.9.15p5-3ubuntu5.24.04.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2143042 ], "author": "Marc Deslauriers ", "date": "Mon, 02 Mar 2026 07:56:19 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "util-linux", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "uuid-runtime", "from_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.4", "version": "2.39.3-9ubuntu6.4" }, "to_version": { "source_package_name": "util-linux", "source_package_version": "2.39.3-9ubuntu6.5", "version": "2.39.3-9ubuntu6.5" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * d/p/ubuntu/su-pty-drop-caps.patch: harden 'su --pty' to temporarily lower", " capabilities while proxying between stdin/stdout and the pty master. This", " is to avoid su from being used to exploit kernel vulnerabilities.", "" ], "package": "util-linux", "version": "2.39.3-9ubuntu6.5", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Luci Stanescu ", "date": "Fri, 06 Mar 2026 18:00:54 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "vim", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.9", "version": "2:9.1.0016-1ubuntu7.9" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.10", "version": "2:9.1.0016-1ubuntu7.10" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.10", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:13:01 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "vim-common", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.9", "version": "2:9.1.0016-1ubuntu7.9" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.10", "version": "2:9.1.0016-1ubuntu7.10" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.10", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:13:01 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "vim-runtime", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.9", "version": "2:9.1.0016-1ubuntu7.9" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.10", "version": "2:9.1.0016-1ubuntu7.10" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.10", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:13:01 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "vim-tiny", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.9", "version": "2:9.1.0016-1ubuntu7.9" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.10", "version": "2:9.1.0016-1ubuntu7.10" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.10", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:13:01 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "xxd", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.9", "version": "2:9.1.0016-1ubuntu7.9" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.10", "version": "2:9.1.0016-1ubuntu7.10" }, "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-26269", "url": "https://ubuntu.com/security/CVE-2026-26269", "cve_description": "Vim is an open source, command line text editor. Prior to 9.1.2148, a stack buffer overflow vulnerability exists in Vim's NetBeans integration when processing the specialKeys command, affecting Vim builds that enable and use the NetBeans feature. The Stack buffer overflow exists in special_keys() (in src/netbeans.c). The while (*tok) loop writes two bytes per iteration into a 64-byte stack buffer (keybuf) with no bounds check. A malicious NetBeans server can overflow keybuf with a single specialKeys command. The issue has been fixed as of Vim patch v9.1.2148.", "cve_priority": "low", "cve_public_date": "2026-02-13 20:17:00 UTC" }, { "cve": "CVE-2026-28420", "url": "https://ubuntu.com/security/CVE-2026-28420", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0076, a heap-based buffer overflow WRITE and an out-of-bounds READ exist in Vim's terminal emulator when processing maximum combining characters from Unicode supplementary planes. Version 9.2.0076 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28422", "url": "https://ubuntu.com/security/CVE-2026-28422", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0078, a stack-buffer-overflow occurs in `build_stl_str_hl()` when rendering a statusline with a multi-byte fill character on a very wide terminal. Version 9.2.0078 patches the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-25749", "url": "https://ubuntu.com/security/CVE-2026-25749", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.1.2132, a heap buffer overflow vulnerability exists in Vim's tag file resolution logic when processing the 'helpfile' option. The vulnerability is located in the get_tagfname() function in src/tag.c. When processing help file tags, Vim copies the user-controlled 'helpfile' option value into a fixed-size heap buffer of MAXPATHL + 1 bytes (typically 4097 bytes) using an unsafe STRCPY() operation without any bounds checking. This issue has been patched in version 9.1.2132.", "cve_priority": "low", "cve_public_date": "2026-02-06 23:15:00 UTC" }, { "cve": "CVE-2026-28417", "url": "https://ubuntu.com/security/CVE-2026-28417", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0073, an OS command injection vulnerability exists in the `netrw` standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the `scp://` protocol handler), an attacker can execute arbitrary shell commands with the privileges of the Vim process. Version 9.2.0073 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28418", "url": "https://ubuntu.com/security/CVE-2026-28418", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0074, a heap-based buffer overflow out-of-bounds read exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file, Vim can be tricked into reading up to 7 bytes beyond the allocated memory boundary. Version 9.2.0074 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28419", "url": "https://ubuntu.com/security/CVE-2026-28419", "cve_description": "Vim is an open source, command line text editor. Prior to version 9.2.0075, a heap-based buffer underflow exists in Vim's Emacs-style tags file parsing logic. When processing a malformed tags file where a delimiter appears at the start of a line, Vim attempts to read memory immediately preceding the allocated buffer. Version 9.2.0075 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" }, { "cve": "CVE-2026-28421", "url": "https://ubuntu.com/security/CVE-2026-28421", "cve_description": "Vim is an open source, command line text editor. Versions prior to 9.2.0077 have a heap-buffer-overflow and a segmentation fault (SEGV) exist in Vim's swap file recovery logic. Both are caused by unvalidated fields read from crafted pointer blocks within a swap file. Version 9.2.0077 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-02-27 22:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer Overflow", " - debian/patches/CVE-2026-26269.patch: Limit writing to max KEYBUFLEN", " bytes to prevent writing out of bounds.", " - debian/patches/CVE-2026-28420.patch: Use VTERM_MAX_CHARS_PER_CELL * 4", " for ga_grow() to ensure sufficient space. Add a boundary check to the", " character loop to prevent index out-of-bounds access.", " - debian/patches/CVE-2026-28422.patch: Update the size check to account", " for the byte length of the fill character (using MB_CHAR2LEN).", " - debian/patches/CVE-2026-25749.patch: Limit strncpy to the length", " of the buffer (MAXPATHL)", " - CVE-2026-26269", " - CVE-2026-28420", " - CVE-2026-28422", " - CVE-2026-25749", " * SECURITY UPDATE: Command Injection", " - debian/patches/CVE-2026-28417.patch: Implement stricter RFC1123", " hostname and IP validation. Use shellescape() for the provided", " hostname and port.", " - CVE-2026-28417", " * SECURITY UPDATE: Out of Bounds Read", " - debian/patches/CVE-2026-28418.patch: Check for end of buffer", " and return early.", " - CVE-2026-28418", " * SECURITY UPDATE: Buffer Underflow", " - debian/patches/CVE-2026-28419.patch: Add a check to ensure the", " delimiter (p_7f) is not at the start of the buffer (lbuf) before", " attempting to isolate the tag name.", " - CVE-2026-28419", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-28421.patch: Add bounds checks on", " pe_page_count and pe_bnum against mf_blocknr_max before descending", " into the block tree, and validate pe_old_lnum >= 1 and", " pe_line_count > 0 before calling readfile().", " - CVE-2026-28421", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.10", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 10 Mar 2026 20:13:01 +1100" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-6.17.0-19-generic", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " [ Ubuntu-riscv: 6.17.0-19.19.1 ]", "", " [ Ubuntu: 6.17.0-19.19 ]", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2143480 ], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:37:14 +0100" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-6.17: 6.17.0-16.16.1~24.04.1 -proposed tracker (LP: #2141143)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-6.17/dkms-versions -- update from kernel-", " versions (main/2026.02.09)", "", " [ Ubuntu-riscv: 6.17.0-16.16.1 ]", "", " * questing/linux-riscv: 6.17.0-16.16.1 -proposed tracker (LP: #2141144)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " [ Ubuntu: 6.17.0-16.16 ]", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:51:40 +0100" } ], "notes": "linux-headers-6.17.0-19-generic version '6.17.0-19.19.1~24.04.1' (source package linux-riscv-6.17 version '6.17.0-19.19.1~24.04.1') was added. linux-headers-6.17.0-19-generic version '6.17.0-19.19.1~24.04.1' has the same source package name, linux-riscv-6.17, as removed package linux-headers-6.17.0-14-generic. As such we can use the source package version of the removed package, '6.17.0-14.14.1~24.04.1', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-6.17.0-19-generic", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " [ Ubuntu-riscv: 6.17.0-19.19.1 ]", "", " [ Ubuntu: 6.17.0-19.19 ]", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2143480 ], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:37:14 +0100" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-6.17: 6.17.0-16.16.1~24.04.1 -proposed tracker (LP: #2141143)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-6.17/dkms-versions -- update from kernel-", " versions (main/2026.02.09)", "", " [ Ubuntu-riscv: 6.17.0-16.16.1 ]", "", " * questing/linux-riscv: 6.17.0-16.16.1 -proposed tracker (LP: #2141144)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " [ Ubuntu: 6.17.0-16.16 ]", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:51:40 +0100" } ], "notes": "linux-image-6.17.0-19-generic version '6.17.0-19.19.1~24.04.1' (source package linux-riscv-6.17 version '6.17.0-19.19.1~24.04.1') was added. linux-image-6.17.0-19-generic version '6.17.0-19.19.1~24.04.1' has the same source package name, linux-riscv-6.17, as removed package linux-headers-6.17.0-14-generic. As such we can use the source package version of the removed package, '6.17.0-14.14.1~24.04.1', 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.17.0-19-generic", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " [ Ubuntu-riscv: 6.17.0-19.19.1 ]", "", " [ Ubuntu: 6.17.0-19.19 ]", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2143480 ], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:37:14 +0100" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-6.17: 6.17.0-16.16.1~24.04.1 -proposed tracker (LP: #2141143)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-6.17/dkms-versions -- update from kernel-", " versions (main/2026.02.09)", "", " [ Ubuntu-riscv: 6.17.0-16.16.1 ]", "", " * questing/linux-riscv: 6.17.0-16.16.1 -proposed tracker (LP: #2141144)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " [ Ubuntu: 6.17.0-16.16 ]", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:51:40 +0100" } ], "notes": "linux-modules-6.17.0-19-generic version '6.17.0-19.19.1~24.04.1' (source package linux-riscv-6.17 version '6.17.0-19.19.1~24.04.1') was added. linux-modules-6.17.0-19-generic version '6.17.0-19.19.1~24.04.1' has the same source package name, linux-riscv-6.17, as removed package linux-headers-6.17.0-14-generic. As such we can use the source package version of the removed package, '6.17.0-14.14.1~24.04.1', 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-riscv-6.17-headers-6.17.0-19", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " [ Ubuntu-riscv: 6.17.0-19.19.1 ]", "", " [ Ubuntu: 6.17.0-19.19 ]", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2143480 ], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:37:14 +0100" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-6.17: 6.17.0-16.16.1~24.04.1 -proposed tracker (LP: #2141143)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-6.17/dkms-versions -- update from kernel-", " versions (main/2026.02.09)", "", " [ Ubuntu-riscv: 6.17.0-16.16.1 ]", "", " * questing/linux-riscv: 6.17.0-16.16.1 -proposed tracker (LP: #2141144)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " [ Ubuntu: 6.17.0-16.16 ]", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:51:40 +0100" } ], "notes": "linux-riscv-6.17-headers-6.17.0-19 version '6.17.0-19.19.1~24.04.1' (source package linux-riscv-6.17 version '6.17.0-19.19.1~24.04.1') was added. linux-riscv-6.17-headers-6.17.0-19 version '6.17.0-19.19.1~24.04.1' has the same source package name, linux-riscv-6.17, as removed package linux-headers-6.17.0-14-generic. As such we can use the source package version of the removed package, '6.17.0-14.14.1~24.04.1', 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-riscv-6.17-tools-6.17.0-19", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " [ Ubuntu-riscv: 6.17.0-19.19.1 ]", "", " [ Ubuntu: 6.17.0-19.19 ]", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2143480 ], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:37:14 +0100" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-6.17: 6.17.0-16.16.1~24.04.1 -proposed tracker (LP: #2141143)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-6.17/dkms-versions -- update from kernel-", " versions (main/2026.02.09)", "", " [ Ubuntu-riscv: 6.17.0-16.16.1 ]", "", " * questing/linux-riscv: 6.17.0-16.16.1 -proposed tracker (LP: #2141144)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " [ Ubuntu: 6.17.0-16.16 ]", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:51:40 +0100" } ], "notes": "linux-riscv-6.17-tools-6.17.0-19 version '6.17.0-19.19.1~24.04.1' (source package linux-riscv-6.17 version '6.17.0-19.19.1~24.04.1') was added. linux-riscv-6.17-tools-6.17.0-19 version '6.17.0-19.19.1~24.04.1' has the same source package name, linux-riscv-6.17, as removed package linux-headers-6.17.0-14-generic. As such we can use the source package version of the removed package, '6.17.0-14.14.1~24.04.1', 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-tools-6.17.0-19-generic", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": null }, "to_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-19.19.1~24.04.1", "version": "6.17.0-19.19.1~24.04.1" }, "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2143480, 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "changes": [ { "cves": [], "log": [ "", " [ Ubuntu-riscv: 6.17.0-19.19.1 ]", "", " [ Ubuntu: 6.17.0-19.19 ]", " * Questing: Failed to query NVIDIA devices (LP: #2143480)", " - [Config] disable NOVA_CORE", " * Miscellaneous upstream changes", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: fix memory leak in verify_header", " - apparmor: replace recursive profile removal with iterative approach", " - apparmor: fix: limit the number of levels of policy namespaces", " - apparmor: fix side-effect bug in match_char() macro usage", " - apparmor: fix missing bounds check on DEFAULT table in verify_dfa()", " - apparmor: Fix double free of ns_name in aa_replace_profiles()", " - apparmor: fix unprivileged local user can do privileged policy", " management", " - apparmor: fix differential encoding verification", " - apparmor: fix race on rawdata dereference", " - apparmor: fix race between freeing data and fs accessing it", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-19.19.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2143480 ], "author": "Manuel Diewald ", "date": "Mon, 09 Mar 2026 11:37:14 +0100" }, { "cves": [ { "cve": "CVE-2025-68344", "url": "https://ubuntu.com/security/CVE-2025-68344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: wavefront: Fix integer overflow in sample size validation The wavefront_send_sample() function has an integer overflow issue when validating sample size. The header->size field is u32 but gets cast to int for comparison with dev->freemem Fix by using unsigned comparison to avoid integer overflow.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68345", "url": "https://ubuntu.com/security/CVE-2025-68345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi() The acpi_get_first_physical_node() function can return NULL, in which case the get_device() function also returns NULL, but this value is then dereferenced without checking,so add a check to prevent a crash. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68346", "url": "https://ubuntu.com/security/CVE-2025-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: dice: fix buffer overflow in detect_stream_formats() The function detect_stream_formats() reads the stream_count value directly from a FireWire device without validating it. This can lead to out-of-bounds writes when a malicious device provides a stream_count value greater than MAX_STREAMS. Fix by applying the same validation to both TX and RX stream counts in detect_stream_formats().", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68323", "url": "https://ubuntu.com/security/CVE-2025-68323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: fix use-after-free caused by uec->work The delayed work uec->work is scheduled in gaokun_ucsi_probe() but never properly canceled in gaokun_ucsi_remove(). This creates use-after-free scenarios where the ucsi and gaokun_ucsi structure are freed after ucsi_destroy() completes execution, while the gaokun_ucsi_register_worker() might be either currently executing or still pending in the work queue. The already-freed gaokun_ucsi or ucsi structure may then be accessed. Furthermore, the race window is 3 seconds, which is sufficiently long to make this bug easily reproducible. The following is the trace captured by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630 Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0 ... Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x78/0x90 print_report+0x114/0x580 kasan_report+0xa4/0xf0 __asan_report_store8_noabort+0x20/0x2c __run_timers+0x5ec/0x630 run_timer_softirq+0xe8/0x1cc handle_softirqs+0x294/0x720 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x30/0x48 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x27c/0x364 irq_exit_rcu+0x10/0x1c el1_interrupt+0x40/0x60 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x6c/0x70 arch_local_irq_enable+0x4/0x8 (P) do_idle+0x334/0x458 cpu_startup_entry+0x60/0x70 rest_init+0x158/0x174 start_kernel+0x2f8/0x394 __primary_switched+0x8c/0x94 Allocated by task 72 on cpu 0 at 27.510341s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c kasan_save_alloc_info+0x40/0x54 __kasan_kmalloc+0xa0/0xb8 __kmalloc_node_track_caller_noprof+0x1c0/0x588 devm_kmalloc+0x7c/0x1c8 gaokun_ucsi_probe+0xa0/0x840 auxiliary_bus_probe+0x94/0xf8 really_probe+0x17c/0x5b8 __driver_probe_device+0x158/0x2c4 driver_probe_device+0x10c/0x264 __device_attach_driver+0x168/0x2d0 bus_for_each_drv+0x100/0x188 __device_attach+0x174/0x368 device_initial_probe+0x14/0x20 bus_probe_device+0x120/0x150 device_add+0xb3c/0x10fc __auxiliary_device_add+0x88/0x130 ... Freed by task 73 on cpu 1 at 28.910627s: kasan_save_stack+0x2c/0x54 kasan_save_track+0x24/0x5c __kasan_save_free_info+0x4c/0x74 __kasan_slab_free+0x60/0x8c kfree+0xd4/0x410 devres_release_all+0x140/0x1f0 device_unbind_cleanup+0x20/0x190 device_release_driver_internal+0x344/0x460 device_release_driver+0x18/0x24 bus_remove_device+0x198/0x274 device_del+0x310/0xa84 ... The buggy address belongs to the object at ffff00000ec28c00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 200 bytes inside of freed 512-byte region The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff) page_type: f5(slab) raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000 head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000 head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================ ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68766", "url": "https://ubuntu.com/security/CVE-2025-68766", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc() If irq_domain_translate_twocell() sets \"hwirq\" to >= MCHP_EIC_NIRQ (2) then it results in an out of bounds access. The code checks for invalid values, but doesn't set the error code. Return -EINVAL in that case, instead of returning success.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68324", "url": "https://ubuntu.com/security/CVE-2025-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: imm: Fix use-after-free bug caused by unfinished delayed work The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands. When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated. However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory. The race condition can occur as follows: CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck() imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USE Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68756", "url": "https://ubuntu.com/security/CVE-2025-68756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock blk_mq_{add,del}_queue_tag_set() functions add and remove queues from tagset, the functions make sure that tagset and queues are marked as shared when two or more queues are attached to the same tagset. Initially a tagset starts as unshared and when the number of added queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along with all the queues attached to it. When the number of attached queues drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and the remaining queues as unshared. Both functions need to freeze current queues in tagset before setting on unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions hold set->tag_list_lock mutex, which makes sense as we do not want queues to be added or deleted in the process. This used to work fine until commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\") made the nvme driver quiesce tagset instead of quiscing individual queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in set->tag_list while holding set->tag_list_lock also. This results in deadlock between two threads with these stacktraces: __schedule+0x47c/0xbb0 ? timerqueue_add+0x66/0xb0 schedule+0x1c/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.constprop.0+0x271/0x600 blk_mq_quiesce_tagset+0x25/0xc0 nvme_dev_disable+0x9c/0x250 nvme_timeout+0x1fc/0x520 blk_mq_handle_expired+0x5c/0x90 bt_iter+0x7e/0x90 blk_mq_queue_tag_busy_iter+0x27e/0x550 ? __blk_mq_complete_request_remote+0x10/0x10 ? __blk_mq_complete_request_remote+0x10/0x10 ? __call_rcu_common.constprop.0+0x1c0/0x210 blk_mq_timeout_work+0x12d/0x170 process_one_work+0x12e/0x2d0 worker_thread+0x288/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 __schedule+0x47c/0xbb0 ? xas_find+0x161/0x1a0 schedule+0x1c/0xa0 blk_mq_freeze_queue_wait+0x3d/0x70 ? destroy_sched_domains_rcu+0x30/0x30 blk_mq_update_tag_set_shared+0x44/0x80 blk_mq_exit_queue+0x141/0x150 del_gendisk+0x25a/0x2d0 nvme_ns_remove+0xc9/0x170 nvme_remove_namespaces+0xc7/0x100 nvme_remove+0x62/0x150 pci_device_remove+0x23/0x60 device_release_driver_internal+0x159/0x200 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x112/0x1e0 vfs_write+0x2b1/0x3d0 ksys_write+0x4e/0xb0 do_syscall_64+0x5b/0x160 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The top stacktrace is showing nvme_timeout() called to handle nvme command timeout. timeout handler is trying to disable the controller and as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not to call queue callback handlers. The thread is stuck waiting for set->tag_list_lock as it tries to walk the queues in set->tag_list. The lock is held by the second thread in the bottom stack which is waiting for one of queues to be frozen. The queue usage counter will drop to zero after nvme_timeout() finishes, and this will not happen because the thread will wait for this mutex forever. Given that [un]quiescing queue is an operation that does not need to sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking set->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU safe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list) in blk_mq_del_queue_tag_set() because we can not re-initialize it while the list is being traversed under RCU. The deleted queue will not be added/deleted to/from a tagset and it will be freed in blk_free_queue() after the end of RCU grace period.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68753", "url": "https://ubuntu.com/security/CVE-2025-68753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: add bounds check in put_user loop for DSP events In the DSP event handling code, a put_user() loop copies event data. When the user buffer size is not aligned to 4 bytes, it could overwrite beyond the buffer boundary. Fix by adding a bounds check before put_user().", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68347", "url": "https://ubuntu.com/security/CVE-2025-68347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events The DSP event handling code in hwdep_read() could write more bytes to the user buffer than requested, when a user provides a buffer smaller than the event header size (8 bytes). Fix by using min_t() to clamp the copy size, This ensures we never copy more than the user requested.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68348", "url": "https://ubuntu.com/security/CVE-2025-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68764", "url": "https://ubuntu.com/security/CVE-2025-68764", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the \"ro\" flag.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68735", "url": "https://ubuntu.com/security/CVE-2025-68735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Prevent potential UAF in group creation This commit prevents the possibility of a use after free issue in the GROUP_CREATE ioctl function, which arose as pointer to the group is accessed in that ioctl function after storing it in the Xarray. A malicious userspace can second guess the handle of a group and try to call GROUP_DESTROY ioctl from another thread around the same time as GROUP_CREATE ioctl. To prevent the use after free exploit, this commit uses a mark on an entry of group pool Xarray which is added just before returning from the GROUP_CREATE ioctl function. The mark is checked for all ioctls that specify the group handle and so userspace won't be abe to delete a group that isn't marked yet. v2: Add R-bs and fixes tags", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68349", "url": "https://ubuntu.com/security/CVE-2025-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid Fixes a crash when layout is null during this call stack: write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inode pnfs_set_layoutcommit relies on the lseg refcount to keep the layout around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt to reference a null layout.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68754", "url": "https://ubuntu.com/security/CVE-2025-68754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rtc: amlogic-a4: fix double free caused by devm The clock obtained via devm_clk_get_enabled() is automatically managed by devres and will be disabled and freed on driver detach. Manually calling clk_disable_unprepare() in error path and remove function causes double free. Remove the redundant clk_disable_unprepare() calls from the probe error path and aml_rtc_remove(), allowing the devm framework to automatically manage the clock lifecycle.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68325", "url": "https://ubuntu.com/security/CVE-2025-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes that the parent qdisc will enqueue the current packet. However, this assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent qdisc stops enqueuing current packet, leaving the tree qlen/backlog accounting inconsistent. This mismatch can lead to a NULL dereference (e.g., when the parent Qdisc is qfq_qdisc). This patch computes the qlen/backlog delta in a more robust way by observing the difference before and after the series of cake_drop() calls, and then compensates the qdisc tree accounting if cake_enqueue() returns NET_XMIT_CN. To ensure correct compensation when ACK thinning is enabled, a new variable is introduced to keep qlen unchanged.", "cve_priority": "medium", "cve_public_date": "2025-12-18 15:16:00 UTC" }, { "cve": "CVE-2025-68762", "url": "https://ubuntu.com/security/CVE-2025-68762", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netpoll: initialize work queue before error checks Prevent a kernel warning when netconsole setup fails on devices with IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in __flush_work) occurs because the cleanup path tries to cancel an uninitialized work queue. When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL, it fails early and calls skb_pool_flush() for cleanup. This function calls cancel_work_sync(&np->refill_wq), but refill_wq hasn't been initialized yet, triggering the warning. Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the work queue is properly initialized before any potential failure points. This allows the cleanup path to safely cancel the work queue regardless of where the setup fails.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68352", "url": "https://ubuntu.com/security/CVE-2025-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: ch341: fix out-of-bounds memory access in ch341_transfer_one Discovered by Atuin - Automated Vulnerability Discovery Engine. The 'len' variable is calculated as 'min(32, trans->len + 1)', which includes the 1-byte command header. When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len' as the length is incorrect because: 1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size 'trans->len', i.e., 'len - 1' in this context). 2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1 overflows the buffer. Fix this by copying 'len - 1' bytes.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68752", "url": "https://ubuntu.com/security/CVE-2025-68752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iavf: Implement settime64 with -EOPNOTSUPP ptp_clock_settime() assumes every ptp_clock has implemented settime64(). Stub it with -EOPNOTSUPP to prevent a NULL dereference. The fix is similar to commit 329d050bbe63 (\"gve: Implement settime64 with -EOPNOTSUPP\").", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68354", "url": "https://ubuntu.com/security/CVE-2025-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to: 1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers. Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68356", "url": "https://ubuntu.com/security/CVE-2025-68356", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: Prevent recursive memory reclaim Function new_inode() returns a new inode with inode->i_mapping->gfp_mask set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so allocations in that address space can recurse into filesystem memory reclaim. We don't want that to happen because it can consume a significant amount of stack memory. Worse than that is that it can also deadlock: for example, in several places, gfs2_unstuff_dinode() is called inside filesystem transactions. This calls filemap_grab_folio(), which can allocate a new folio, which can trigger memory reclaim. If memory reclaim recurses into the filesystem and starts another transaction, a deadlock will ensue. To fix these kinds of problems, prevent memory reclaim from recursing into filesystem code by making sure that the gfp_mask of inode address spaces doesn't include __GFP_FS. The \"meta\" and resource group address spaces were already using GFP_NOFS as their gfp_mask (which doesn't include __GFP_FS). The default value of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To avoid being overly limiting, use the default value and only knock off the __GFP_FS flag. I'm not sure if this will actually make a difference, but it also shouldn't hurt. This patch is loosely based on commit ad22c7a043c2 (\"xfs: prevent stack overflows from page cache allocation\"). Fixes xfstest generic/273.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68758", "url": "https://ubuntu.com/security/CVE-2025-68758", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: backlight: led-bl: Add devlink to supplier LEDs LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = \"nxp,pca9632\"; reg = <0x62>; \t// ... addon_led_pwm: led-pwm@3 { reg = <3>; label = \"addon:led:pwm\"; }; }; backlight-addon { compatible = \"led-backlight\"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68358", "url": "https://ubuntu.com/security/CVE-2025-68358", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68359", "url": "https://ubuntu.com/security/CVE-2025-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double free of qgroup record after failure to add delayed ref head In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee. The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic. As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit. The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68765", "url": "https://ubuntu.com/security/CVE-2025-68765", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add() In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function returns an error without freeing sskb, leading to a memory leak. Fix this by calling dev_kfree_skb() on sskb in the error handling path to ensure it is properly released.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68360", "url": "https://ubuntu.com/security/CVE-2025-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks MT7996 driver can use both wed and wed_hif2 devices to offload traffic from/to the wireless NIC. In the current codebase we assume to always use the primary wed device in wed callbacks resulting in the following crash if the hw runs wed_hif2 (e.g. 6GHz link). [ 297.455876] Unable to handle kernel read from unreadable memory at virtual address 000000000000080a [ 297.464928] Mem abort info: [ 297.467722] ESR = 0x0000000096000005 [ 297.471461] EC = 0x25: DABT (current EL), IL = 32 bits [ 297.476766] SET = 0, FnV = 0 [ 297.479809] EA = 0, S1PTW = 0 [ 297.482940] FSC = 0x05: level 1 translation fault [ 297.487809] Data abort info: [ 297.490679] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 297.496156] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 297.501196] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 297.506500] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000107480000 [ 297.512927] [000000000000080a] pgd=08000001097fb003, p4d=08000001097fb003, pud=08000001097fb003, pmd=0000000000000000 [ 297.523532] Internal error: Oops: 0000000096000005 [#1] SMP [ 297.715393] CPU: 2 UID: 0 PID: 45 Comm: kworker/u16:2 Tainted: G O 6.12.50 #0 [ 297.723908] Tainted: [O]=OOT_MODULE [ 297.727384] Hardware name: Banana Pi BPI-R4 (2x SFP+) (DT) [ 297.732857] Workqueue: nf_ft_offload_del nf_flow_rule_route_ipv6 [nf_flow_table] [ 297.740254] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 297.747205] pc : mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.752688] lr : mtk_wed_flow_remove+0x58/0x80 [ 297.757126] sp : ffffffc080fe3ae0 [ 297.760430] x29: ffffffc080fe3ae0 x28: ffffffc080fe3be0 x27: 00000000deadbef7 [ 297.767557] x26: ffffff80c5ebca00 x25: 0000000000000001 x24: ffffff80c85f4c00 [ 297.774683] x23: ffffff80c1875b78 x22: ffffffc080d42cd0 x21: ffffffc080660018 [ 297.781809] x20: ffffff80c6a076d0 x19: ffffff80c6a043c8 x18: 0000000000000000 [ 297.788935] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000 [ 297.796060] x14: 0000000000000019 x13: ffffff80c0ad8ec0 x12: 00000000fa83b2da [ 297.803185] x11: ffffff80c02700c0 x10: ffffff80c0ad8ec0 x9 : ffffff81fef96200 [ 297.810311] x8 : ffffff80c02700c0 x7 : ffffff80c02700d0 x6 : 0000000000000002 [ 297.817435] x5 : 0000000000000400 x4 : 0000000000000000 x3 : 0000000000000000 [ 297.824561] x2 : 0000000000000001 x1 : 0000000000000800 x0 : ffffff80c6a063c8 [ 297.831686] Call trace: [ 297.834123] mt76_wed_offload_disable+0x64/0xa0 [mt76] [ 297.839254] mtk_wed_flow_remove+0x58/0x80 [ 297.843342] mtk_flow_offload_cmd+0x434/0x574 [ 297.847689] mtk_wed_setup_tc_block_cb+0x30/0x40 [ 297.852295] nf_flow_offload_ipv6_hook+0x7f4/0x964 [nf_flow_table] [ 297.858466] nf_flow_rule_route_ipv6+0x438/0x4a4 [nf_flow_table] [ 297.864463] process_one_work+0x174/0x300 [ 297.868465] worker_thread+0x278/0x430 [ 297.872204] kthread+0xd8/0xdc [ 297.875251] ret_from_fork+0x10/0x20 [ 297.878820] Code: 928b5ae0 8b000273 91400a60 f943fa61 (79401421) [ 297.884901] ---[ end trace 0000000000000000 ]--- Fix the issue detecting the proper wed reference to use running wed callabacks.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68738", "url": "https://ubuntu.com/security/CVE-2025-68738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx() If a link does not have an assigned channel yet, mt7996_vif_link returns NULL. We still need to store the updated queue settings in that case, and apply them later. Move the location of the queue params to within struct mt7996_vif_link.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68361", "url": "https://ubuntu.com/security/CVE-2025-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: limit the level of fs stacking for file-backed mounts Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68739", "url": "https://ubuntu.com/security/CVE-2025-68739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: hisi: Fix potential UAF in OPP handling Ensure all required data is acquired before calling dev_pm_opp_put(opp) to maintain correct resource acquisition and release order.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68763", "url": "https://ubuntu.com/security/CVE-2025-68763", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Correctly handle return of sg_nents_for_len The return value of sg_nents_for_len was assigned to an unsigned long in starfive_hash_digest, causing negative error codes to be converted to large positive integers. Add error checking for sg_nents_for_len and return immediately on failure to prevent potential buffer overflows.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68740", "url": "https://ubuntu.com/security/CVE-2025-68740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: Handle error code returned by ima_filter_rule_match() In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to the rule being NULL, the function incorrectly skips the 'if (!rc)' check and sets 'result = true'. The LSM rule is considered a match, causing extra files to be measured by IMA. This issue can be reproduced in the following scenario: After unloading the SELinux policy module via 'semodule -d', if an IMA measurement is triggered before ima_lsm_rules is updated, in ima_match_rules(), the first call to ima_filter_rule_match() returns -ESTALE. This causes the code to enter the 'if (rc == -ESTALE && !rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In ima_lsm_copy_rule(), since the SELinux module has been removed, the rule becomes NULL, and the second call to ima_filter_rule_match() returns -ENOENT. This bypasses the 'if (!rc)' check and results in a false match. Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0 Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error codes like -ENOENT do not bypass the check and accidentally result in a successful match.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68362", "url": "https://ubuntu.com/security/CVE-2025-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb() The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header. If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic. Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68741", "url": "https://ubuntu.com/security/CVE-2025-68741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix improper freeing of purex item In qla2xxx_process_purls_iocb(), an item is allocated via qla27xx_copy_multiple_pkt(), which internally calls qla24xx_alloc_purex_item(). The qla24xx_alloc_purex_item() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc(). An error handling path in qla2xxx_process_purls_iocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption. Fix this by using the correct deallocation function, qla24xx_free_purex_item(), which properly handles both dynamically allocated and pre-allocated items.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68742", "url": "https://ubuntu.com/security/CVE-2025-68742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix invalid prog->stats access when update_effective_progs fails Syzkaller triggers an invalid memory access issue following fault injection in update_effective_progs. The issue can be described as follows: __cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog ---softirq start--- __do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp) ---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype]) The reason is that fault injection caused update_effective_progs to fail and then changed the original prog into dummy_bpf_prog.prog in purge_effective_progs. Then a softirq came, and accessing the members of dummy_bpf_prog.prog in the softirq triggers invalid mem access. To fix it, skip updating stats when stats is NULL.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68759", "url": "https://ubuntu.com/security/CVE-2025-68759", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring() In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA allocations in a loop. When an allocation fails, the previously successful allocations are not freed on exit. Fix that by jumping to err_free_rings label on error, which calls rtl8180_free_rx_ring() to free the allocations. Remove the free of rx_ring in rtl8180_init_rx_ring() error path, and set the freed priv->rx_buf entry to null, to avoid double free.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68743", "url": "https://ubuntu.com/security/CVE-2025-68743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix create memory region overlap check The current check is incorrect; it only checks if the beginning or end of a region is within an existing region. This doesn't account for userspace specifying a region that begins before and ends after an existing region. Change the logic to a range intersection check against gfns and uaddrs for each region. Remove mshv_partition_region_by_uaddr() as it is no longer used.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68363", "url": "https://ubuntu.com/security/CVE-2025-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check skb->transport_header is set in bpf_skb_check_mtu The bpf_skb_check_mtu helper needs to use skb->transport_header when the BPF_MTU_CHK_SEGS flag is used: \tbpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS) The transport_header is not always set. There is a WARN_ON_ONCE report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set + bpf_prog_test_run is used: WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skb For a normal ingress skb (not test_run), skb_reset_transport_header is performed but there is plan to avoid setting it as described in commit 2170a1f09148 (\"net: no longer reset transport_header in __netif_receive_skb_core()\"). This patch fixes the bpf helper by checking skb_transport_header_was_set(). The check is done just before skb->transport_header is used, to avoid breaking the existing bpf prog. The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68751", "url": "https://ubuntu.com/security/CVE-2025-68751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/fpu: Fix false-positive kmsan report in fpu_vstl() A false-positive kmsan report is detected when running ping command. An inline assembly instruction 'vstl' can write varied amount of bytes depending on value of 'index' argument. If 'index' > 0, 'vstl' writes at least 2 bytes. clang generates kmsan write helper call depending on inline assembly constraints. Constraints are evaluated compile-time, but value of 'index' argument is known only at runtime. clang currently generates call to __msan_instrument_asm_store with 1 byte as size. Manually call kmsan function to indicate correct amount of bytes written and fix false-positive report. This change fixes following kmsan reports: [ 36.563119] ===================================================== [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 36.563852] virtqueue_add+0x35c6/0x7c70 [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0 [ 36.564266] start_xmit+0x288c/0x4a20 [ 36.564460] dev_hard_start_xmit+0x302/0x900 [ 36.564649] sch_direct_xmit+0x340/0xea0 [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0 [ 36.565058] neigh_resolve_output+0x936/0xb40 [ 36.565278] __neigh_update+0x2f66/0x3a60 [ 36.565499] neigh_update+0x52/0x60 [ 36.565683] arp_process+0x1588/0x2de0 [ 36.565916] NF_HOOK+0x1da/0x240 [ 36.566087] arp_rcv+0x3e4/0x6e0 [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0 [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0 [ 36.566710] napi_complete_done+0x376/0x740 [ 36.566918] virtnet_poll+0x1bae/0x2910 [ 36.567130] __napi_poll+0xf4/0x830 [ 36.567294] net_rx_action+0x97c/0x1ed0 [ 36.567556] handle_softirqs+0x306/0xe10 [ 36.567731] irq_exit_rcu+0x14c/0x2e0 [ 36.567910] do_io_irq+0xd4/0x120 [ 36.568139] io_int_handler+0xc2/0xe8 [ 36.568299] arch_cpu_idle+0xb0/0xc0 [ 36.568540] arch_cpu_idle+0x76/0xc0 [ 36.568726] default_idle_call+0x40/0x70 [ 36.568953] do_idle+0x1d6/0x390 [ 36.569486] cpu_startup_entry+0x9a/0xb0 [ 36.569745] rest_init+0x1ea/0x290 [ 36.570029] start_kernel+0x95e/0xb90 [ 36.570348] startup_continue+0x2e/0x40 [ 36.570703] [ 36.570798] Uninit was created at: [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0 [ 36.571261] kmalloc_reserve+0x12a/0x470 [ 36.571553] __alloc_skb+0x310/0x860 [ 36.571844] __ip_append_data+0x483e/0x6a30 [ 36.572170] ip_append_data+0x11c/0x1e0 [ 36.572477] raw_sendmsg+0x1c8c/0x2180 [ 36.572818] inet_sendmsg+0xe6/0x190 [ 36.573142] __sys_sendto+0x55e/0x8e0 [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0 [ 36.573571] __do_syscall+0x12e/0x240 [ 36.573823] system_call+0x6e/0x90 [ 36.573976] [ 36.574017] Byte 35 of 98 is uninitialized [ 36.574082] Memory access of size 98 starts at 0000000007aa0012 [ 36.574218] [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux) [ 36.574755] ===================================================== [ 63.532541] ===================================================== [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70 [ 63.533989] virtqueue_add+0x35c6/0x7c70 [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0 [ 63.535861] start_xmit+0x288c/0x4a20 [ 63.536708] dev_hard_start_xmit+0x302/0x900 [ 63.537020] sch_direct_xmit+0x340/0xea0 [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0 [ 63.538819] neigh_resolve_output+0x936/0xb40 [ 63.539793] ip_finish_output2+0x1ee2/0x2200 [ 63.540784] __ip_finish_output+0x272/0x7a0 [ 63.541765] ip_finish_output+0x4e/0x5e0 [ 63.542791] ip_output+0x166/0x410 [ 63.543771] ip_push_pending_frames+0x1a2/0x470 [ 63.544753] raw_sendmsg+0x1f06/0x2180 [ 63.545033] inet_sendmsg+0xe6/0x190 [ 63.546006] __sys_sendto+0x55e/0x8e0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68744", "url": "https://ubuntu.com/security/CVE-2025-68744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free special fields when update [lru_,]percpu_hash maps As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68364", "url": "https://ubuntu.com/security/CVE-2025-68364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent() In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just to avoid crashing the whole kernel due to a filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:15:00 UTC" }, { "cve": "CVE-2025-68366", "url": "https://ubuntu.com/security/CVE-2025-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config unlock in nbd_genl_connect There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK: nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3 recv_work done // config_refs=2 \t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1 \t\t\t\t\t\tclose nbd // config_refs=0 refcount_inc -> uaf ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790 The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); + printk(\"before sleep\\n\"); + mdelay(5 * 1000); + printk(\"after sleep\\n\"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68367", "url": "https://ubuntu.com/security/CVE-2025-68367", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse The following warning appears when running syzkaller, and this issue also exists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock() Fix this by moving the old_val read inside the mutex lock region.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68369", "url": "https://ubuntu.com/security/CVE-2025-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: init run lock for extend inode After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot. Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered. Add the run_lock initialization when loading $Extend. syzbot reported: INFO: trying to register non-static key. Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68370", "url": "https://ubuntu.com/security/CVE-2025-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: tmc: add the handle of the event to the path The handle is essential for retrieving the AUX_EVENT of each CPU and is required in perf mode. It has been added to the coresight_path so that dependent devices can access it from the path when needed. The existing bug can be reproduced with: perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null Showing an oops as follows: Unable to handle kernel paging request at virtual address 000f6e84934ed19e Call trace: tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P) catu_enable_hw+0xbc/0x3d0 [coresight_catu] catu_enable+0x70/0xe0 [coresight_catu] coresight_enable_path+0xb0/0x258 [coresight]", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68755", "url": "https://ubuntu.com/security/CVE-2025-68755", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: remove broken i2c driver The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging. Specifically, commit 723de0f9171e (\"staging: most: remove device from interface structure\") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68371", "url": "https://ubuntu.com/security/CVE-2025-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix device resources accessed after device removal Correct possible race conditions during device removal. Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues. This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources. - Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped. - Cancel any pending TMF work that has not started in sdev_destroy(). - Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68372", "url": "https://ubuntu.com/security/CVE-2025-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: defer config put in recv_work There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open\t // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd\t // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open \t // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put \t // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF Commit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the waiter\") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared. However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup. Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave. In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock): path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0 Depends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68373", "url": "https://ubuntu.com/security/CVE-2025-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: avoid repeated calls to del_gendisk There is a uaf problem which is found by case 23rdev-lifetime: Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace: __del_gendisk+0x356/0x3e0 mddev_unlock+0x351/0x360 rdev_attr_store+0x217/0x280 kernfs_fop_write_iter+0x14a/0x210 vfs_write+0x29e/0x550 ksys_write+0x74/0xf0 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68374", "url": "https://ubuntu.com/security/CVE-2025-68374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: fix rcu protection in md_wakeup_thread We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68375", "url": "https://ubuntu.com/security/CVE-2025-68375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/x86: Fix NULL event access and potential PEBS record loss When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68376", "url": "https://ubuntu.com/security/CVE-2025-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: coresight: ETR: Fix ETR buffer use-after-free issue When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue. Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68746", "url": "https://ubuntu.com/security/CVE-2025-68746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Fix timeout handling When the CPU that the QSPI interrupt handler runs on (typically CPU 0) is excessively busy, it can lead to rare cases of the IRQ thread not running before the transfer timeout is reached. While handling the timeouts, any pending transfers are cleaned up and the message that they correspond to is marked as failed, which leaves the curr_xfer field pointing at stale memory. To avoid this, clear curr_xfer to NULL upon timeout and check for this condition when the IRQ thread is finally run. While at it, also make sure to clear interrupts on failure so that new interrupts can be run. A better, more involved, fix would move the interrupt clearing into a hard IRQ handler. Ideally we would also want to signal that the IRQ thread no longer needs to be run after the timeout is hit to avoid the extra check for a valid transfer.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68760", "url": "https://ubuntu.com/security/CVE-2025-68760", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show In iommu_mmio_write(), it validates the user-provided offset with the check: `iommu->dbg_mmio_offset > iommu->mmio_phys_end - 4`. This assumes a 4-byte access. However, the corresponding show handler, iommu_mmio_show(), uses readq() to perform an 8-byte (64-bit) read. If a user provides an offset equal to `mmio_phys_end - 4`, the check passes, and will lead to a 4-byte out-of-bounds read. Fix this by adjusting the boundary check to use sizeof(u64), which corresponds to the size of the readq() operation.", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68747", "url": "https://ubuntu.com/security/CVE-2025-68747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF on kernel BO VA nodes If the MMU is down, panthor_vm_unmap_range() might return an error. We expect the page table to be updated still, and if the MMU is blocked, the rest of the GPU should be blocked too, so no risk of accessing physical memory returned to the system (which the current code doesn't cover for anyway). Proceed with the rest of the cleanup instead of bailing out and leaving the va_node inserted in the drm_mm, which leads to UAF when other adjacent nodes are removed from the drm_mm tree.", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68748", "url": "https://ubuntu.com/security/CVE-2025-68748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix UAF race between device unplug and FW event processing The function panthor_fw_unplug() will free the FW memory sections. The problem is that there could still be pending FW events which are yet not handled at this point. process_fw_events_work() can in this case try to access said freed memory. Simply call disable_work_sync() to both drain and prevent future invocation of process_fw_events_work().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68749", "url": "https://ubuntu.com/security/CVE-2025-68749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind().", "cve_priority": "medium", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2025-68378", "url": "https://ubuntu.com/security/CVE-2025-68378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check in __bpf_get_stackid() Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68379", "url": "https://ubuntu.com/security/CVE-2025-68379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix null deref on srq->rq.queue after resize failure A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask. Call Trace: rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68380", "url": "https://ubuntu.com/security/CVE-2025-68380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix peer HE MCS assignment In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to firmware as receive MCS while peer's receive MCS sent as transmit MCS, which goes against firmwire's definition. While connecting to a misbehaved AP that advertises 0xffff (meaning not supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff is assigned to he_mcs->rx_mcs_set field. \tExt Tag: HE Capabilities \t [...] \t Supported HE-MCS and NSS Set \t\t[...] \t Rx and Tx MCS Maps 160 MHz \t\t [...] \t Tx HE-MCS Map 160 MHz: 0xffff Swap the assignment to fix this issue. As the HE rate control mask is meant to limit our own transmit MCS, it needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping done, change is needed as well to apply it to the peer's receive MCS. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68724", "url": "https://ubuntu.com/security/CVE-2025-68724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68726", "url": "https://ubuntu.com/security/CVE-2025-68726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: aead - Fix reqsize handling Commit afddce13ce81d (\"crypto: api - Add reqsize to crypto_alg\") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1] Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework. [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68727", "url": "https://ubuntu.com/security/CVE-2025-68727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Fix uninit buffer allocated by __getname() Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68728", "url": "https://ubuntu.com/security/CVE-2025-68728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: fix uninit memory after failed mi_read in mi_format_new Fix a KMSAN un-init bug found by syzkaller. ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN. Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68729", "url": "https://ubuntu.com/security/CVE-2025-68729", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix MSDU buffer types handling in RX error path Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks. Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68757", "url": "https://ubuntu.com/security/CVE-2025-68757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vgem-fence: Fix potential deadlock on release A timer that expires a vgem fence automatically in 10 seconds is now released with timer_delete_sync() from fence->ops.release() called on last dma_fence_put(). In some scenarios, it can run in IRQ context, which is not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while working on new IGT subtests syncobj_timeline@stress-* as user space replacements of some problematic test cases of a dma-fence-chain selftest [1]. [117.004338] ================================ [117.004340] WARNING: inconsistent lock state [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U [117.004346] -------------------------------- [117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes: [117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190 [117.004361] {HARDIRQ-ON-W} state was registered at: [117.004363] lock_acquire+0xc4/0x2e0 [117.004366] call_timer_fn+0x80/0x2a0 [117.004368] __run_timers+0x231/0x310 [117.004370] run_timer_softirq+0x76/0xe0 [117.004372] handle_softirqs+0xd4/0x4d0 [117.004375] __irq_exit_rcu+0x13f/0x160 [117.004377] irq_exit_rcu+0xe/0x20 [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0 [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20 [117.004385] cpuidle_enter_state+0x12b/0x8a0 [117.004388] cpuidle_enter+0x2e/0x50 [117.004393] call_cpuidle+0x22/0x60 [117.004395] do_idle+0x1fd/0x260 [117.004398] cpu_startup_entry+0x29/0x30 [117.004401] start_secondary+0x12d/0x160 [117.004404] common_startup_64+0x13e/0x141 [117.004407] irq event stamp: 2282669 [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80 [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0 [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18 [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160 [117.004426] other info that might help us debug this: [117.004429] Possible unsafe locking scenario: [117.004432] CPU0 [117.004433] ---- [117.004434] lock((&fence->timer)); [117.004436] [117.004438] lock((&fence->timer)); [117.004440] *** DEADLOCK *** [117.004443] 1 lock held by swapper/0/0: [117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0 [117.004450] stack backtrace: [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary) [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 [117.004456] Call Trace: [117.004456] [117.004457] dump_stack_lvl+0x91/0xf0 [117.004460] dump_stack+0x10/0x20 [117.004461] print_usage_bug.part.0+0x260/0x360 [117.004463] mark_lock+0x76e/0x9c0 [117.004465] ? register_lock_class+0x48/0x4a0 [117.004467] __lock_acquire+0xbc3/0x2860 [117.004469] lock_acquire+0xc4/0x2e0 [117.004470] ? __timer_delete_sync+0x4b/0x190 [117.004472] ? __timer_delete_sync+0x4b/0x190 [117.004473] __timer_delete_sync+0x68/0x190 [117.004474] ? __timer_delete_sync+0x4b/0x190 [117.004475] timer_delete_sync+0x10/0x20 [117.004476] vgem_fence_release+0x19/0x30 [vgem] [117.004478] dma_fence_release+0xc1/0x3b0 [117.004480] ? dma_fence_release+0xa1/0x3b0 [117.004481] dma_fence_chain_release+0xe7/0x130 [117.004483] dma_fence_release+0xc1/0x3b0 [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80 [117.004485] dma_fence_chain_irq_work+0x59/0x80 [117.004487] irq_work_single+0x75/0xa0 [117.004490] irq_work_r ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-05 10:15:00 UTC" }, { "cve": "CVE-2025-68730", "url": "https://ubuntu.com/security/CVE-2025-68730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context() Don't add BO to the vdev->bo_list in ivpu_gem_create_object(). When failure happens inside drm_gem_shmem_create(), the BO is not fully created and ivpu_gem_bo_free() callback will not be called causing a deleted BO to be left on the list.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68732", "url": "https://ubuntu.com/security/CVE-2025-68732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix race in syncpt alloc/free Fix race condition between host1x_syncpt_alloc() and host1x_syncpt_put() by using kref_put_mutex() instead of kref_put() + manual mutex locking. This ensures no thread can acquire the syncpt_mutex after the refcount drops to zero but before syncpt_release acquires it. This prevents races where syncpoints could be allocated while still being cleaned up from a previous release. Remove explicit mutex locking in syncpt_release as kref_put_mutex() handles this atomically.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68733", "url": "https://ubuntu.com/security/CVE-2025-68733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smack: fix bug: unprivileged task can create labels If an unprivileged task is allowed to relabel itself (/smack/relabel-self is not empty), it can freely create new labels by writing their names into own /proc/PID/attr/smack/current This occurs because do_setattr() imports the provided label in advance, before checking \"relabel-self\" list. This change ensures that the \"relabel-self\" list is checked before importing the label.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-68282", "url": "https://ubuntu.com/security/CVE-2025-68282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: fix use-after-free in usb_gadget_state_work A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c (\"usb: gadget: core: flush gadget workqueue after device removal\") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68283", "url": "https://ubuntu.com/security/CVE-2025-68283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace BUG_ON with bounds check for map->max_osd OSD indexes come from untrusted network packets. Boundary checks are added to validate these against map->max_osd. [ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68284", "url": "https://ubuntu.com/security/CVE-2025-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds writes in handle_auth_session_key() The len field originates from untrusted network packets. Boundary checks have been added to prevent potential out-of-bounds writes when decrypting the connection secret or processing service tickets. [ idryomov: changelog ]", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68285", "url": "https://ubuntu.com/security/CVE-2025-68285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: fix potential use-after-free in have_mon_and_osd_map() The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap; under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch; condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth(). monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68338", "url": "https://ubuntu.com/security/CVE-2025-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: Don't free uninitialized ksz_irq If something goes wrong at setup, ksz_irq_free() can be called on uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It leads to freeing uninitialized IRQ numbers and/or domains. Use dsa_switch_for_each_user_port_continue_reverse() in the error path to iterate only over the fully initialized ports.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68286", "url": "https://ubuntu.com/security/CVE-2025-68286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check NULL before accessing [WHAT] IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic fails with NULL pointer dereference. This can be reproduced with both an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted 6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ... (cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68326", "url": "https://ubuntu.com/security/CVE-2025-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix stack_depot usage Add missing stack_depot_init() call when CONFIG_DRM_XE_DEBUG_GUC is enabled to fix the following call stack: \t[] BUG: kernel NULL pointer dereference, address: 0000000000000000 \t[] Workqueue: drm_sched_run_job_work [gpu_sched] \t[] RIP: 0010:stack_depot_save_flags+0x172/0x870 \t[] Call Trace: \t[] \t[] fast_req_track+0x58/0xb0 [xe] (cherry picked from commit 64fdf496a6929a0a194387d2bb5efaf5da2b542f)", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68287", "url": "https://ubuntu.com/security/CVE-2025-68287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths This patch addresses a race condition caused by unsynchronized execution of multiple call paths invoking `dwc3_remove_requests()`, leading to premature freeing of USB requests and subsequent crashes. Three distinct execution paths interact with `dwc3_remove_requests()`: Path 1: Triggered via `dwc3_gadget_reset_interrupt()` during USB reset handling. The call stack includes: - `dwc3_ep0_reset_state()` - `dwc3_ep0_stall_and_restart()` - `dwc3_ep0_out_start()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 2: Also initiated from `dwc3_gadget_reset_interrupt()`, but through `dwc3_stop_active_transfers()`. The call stack includes: - `dwc3_stop_active_transfers()` - `dwc3_remove_requests()` - `dwc3_gadget_del_and_unmap_request()` Path 3: Occurs independently during `adb root` execution, which triggers USB function unbind and bind operations. The sequence includes: - `gserial_disconnect()` - `usb_ep_disable()` - `dwc3_gadget_ep_disable()` - `dwc3_remove_requests()` with `-ESHUTDOWN` status Path 3 operates asynchronously and lacks synchronization with Paths 1 and 2. When Path 3 completes, it disables endpoints and frees 'out' requests. If Paths 1 or 2 are still processing these requests, accessing freed memory leads to a crash due to use-after-free conditions. To fix this added check for request completion and skip processing if already completed and added the request status for ep0 while queue.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68331", "url": "https://ubuntu.com/security/CVE-2025-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer When a UAS device is unplugged during data transfer, there is a probability of a system panic occurring. The root cause is an access to an invalid memory address during URB callback handling. Specifically, this happens when the dma_direct_unmap_sg() function is called within the usb_hcd_unmap_urb_for_dma() interface, but the sg->dma_address field is 0 and the sg data structure has already been freed. The SCSI driver sends transfer commands by invoking uas_queuecommand_lck() in uas.c, using the uas_submit_urbs() function to submit requests to USB. Within the uas_submit_urbs() implementation, three URBs (sense_urb, data_urb, and cmd_urb) are sequentially submitted. Device removal may occur at any point during uas_submit_urbs execution, which may result in URB submission failure. However, some URBs might have been successfully submitted before the failure, and uas_submit_urbs will return the -ENODEV error code in this case. The current error handling directly calls scsi_done(). In the SCSI driver, this eventually triggers scsi_complete() to invoke scsi_end_request() for releasing the sgtable. The successfully submitted URBs, when being unlinked to giveback, call usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg unmapping operations since the sg data structure has already been freed. This patch modifies the error condition check in the uas_submit_urbs() function. When a UAS device is removed but one or more URBs have already been successfully submitted to USB, it avoids immediately invoking scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully submitted URBs is completed before devinfo->resetting being set, then the scsi_done() function will be called within uas_try_complete() after all pending URB operations are finalized. Otherwise, the scsi_done() function will be called within uas_zap_pending(), which is executed after usb_kill_anchored_urbs(). The error handling only takes effect when uas_queuecommand_lck() calls uas_submit_urbs() and returns the error value -ENODEV . In this case, the device is disconnected, and the flow proceeds to uas_disconnect(), where uas_zap_pending() is invoked to call uas_try_complete().", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-40345", "url": "https://ubuntu.com/security/CVE-2025-40345", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: sddr55: Reject out-of-bound new_pba Discovered by Atuin - Automated Vulnerability Discovery Engine. new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory. Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.", "cve_priority": "medium", "cve_public_date": "2025-12-12 18:15:00 UTC" }, { "cve": "CVE-2025-68288", "url": "https://ubuntu.com/security/CVE-2025-68288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68327", "url": "https://ubuntu.com/security/CVE-2025-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Fix synchronous external abort on unbind A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo \"0x1d6b\" > idVendor echo \"0x0104\" > idProduct mkdir -p strings/0x409 echo \"0123456789\" > strings/0x409/serialnumber echo \"Renesas.\" > strings/0x409/manufacturer echo \"Ethernet Gadget\" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo \"ECM\" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68289", "url": "https://ubuntu.com/security/CVE-2025-68289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_eem: Fix memory leak in eem_unwrap The existing code did not handle the failure case of usb_ep_queue in the command path, potentially leading to memory leaks. Improve error handling to free all allocated resources on usb_ep_queue failure. This patch continues to use goto logic for error handling, as the existing error handling is complex and not easily adaptable to auto-cleanup helpers. kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68290", "url": "https://ubuntu.com/security/CVE-2025-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: most: usb: fix double free on late probe failure The MOST subsystem has a non-standard registration function which frees the interface on registration failures and on deregistration. This unsurprisingly leads to bugs in the MOST drivers, and a couple of recent changes turned a reference underflow and use-after-free in the USB driver into several double free and a use-after-free on late probe failures.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68292", "url": "https://ubuntu.com/security/CVE-2025-68292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/memfd: fix information leak in hugetlb folios When allocating hugetlb folios for memfd, three initialization steps are missing: 1. Folios are not zeroed, leading to kernel memory disclosure to userspace 2. Folios are not marked uptodate before adding to page cache 3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache() The memfd allocation path bypasses the normal page fault handler (hugetlb_no_page) which would handle all of these initialization steps. This is problematic especially for udmabuf use cases where folios are pinned and directly accessed by userspace via DMA. Fix by matching the initialization pattern used in hugetlb_no_page(): - Zero the folio using folio_zero_user() which is optimized for huge pages - Mark it uptodate with folio_mark_uptodate() - Take hugetlb_fault_mutex before adding to page cache to prevent races The folio_zero_user() change also fixes a potential security issue where uninitialized kernel memory could be disclosed to userspace through read() or mmap() operations on the memfd.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68293", "url": "https://ubuntu.com/security/CVE-2025-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f (\"mm: thp: split huge page to any lower order pages\") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68328", "url": "https://ubuntu.com/security/CVE-2025-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix bug in saving controller data Fix the incorrect usage of platform_set_drvdata and dev_set_drvdata. They both are of the same data and overrides each other. This resulted in the rmmod of the svc driver to fail and throw a kernel panic for kthread_stop and fifo free.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68294", "url": "https://ubuntu.com/security/CVE-2025-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/net: ensure vectored buffer node import is tied to notification When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification io_kiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct io_kiocb for the vectored buffer import.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68295", "url": "https://ubuntu.com/security/CVE-2025-68295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix memory leak in cifs_construct_tcon() When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon(). This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm \"ls\", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68296", "url": "https://ubuntu.com/security/CVE-2025-68296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs. VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array. Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly. Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all(). Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68297", "url": "https://ubuntu.com/security/CVE-2025-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix crash in process_v2_sparse_read() for encrypted directories The crash in process_v2_sparse_read() for fscrypt-encrypted directories has been reported. Issue takes place for Ceph msgr2 protocol in secure mode. It can be reproduced by the steps: sudo mount -t ceph :/ /mnt/cephfs/ -o name=admin,fs=cephfs,ms_mode=secure (1) mkdir /mnt/cephfs/fscrypt-test-3 (2) cp area_decrypted.tar /mnt/cephfs/fscrypt-test-3 (3) fscrypt encrypt --source=raw_key --key=./my.key /mnt/cephfs/fscrypt-test-3 (4) fscrypt lock /mnt/cephfs/fscrypt-test-3 (5) fscrypt unlock --key=my.key /mnt/cephfs/fscrypt-test-3 (6) cat /mnt/cephfs/fscrypt-test-3/area_decrypted.tar (7) Issue has been triggered [ 408.072247] ------------[ cut here ]------------ [ 408.072251] WARNING: CPU: 1 PID: 392 at net/ceph/messenger_v2.c:865 ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072267] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec kvm_intel joydev kvm irqbypass polyval_clmulni ghash_clmulni_intel aesni_intel rapl input_leds psmouse serio_raw i2c_piix4 vga16fb bochs vgastate i2c_smbus floppy mac_hid qemu_fw_cfg pata_acpi sch_fq_codel rbd msr parport_pc ppdev lp parport efi_pstore [ 408.072304] CPU: 1 UID: 0 PID: 392 Comm: kworker/1:3 Not tainted 6.17.0-rc7+ [ 408.072307] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014 [ 408.072310] Workqueue: ceph-msgr ceph_con_workfn [ 408.072314] RIP: 0010:ceph_con_v2_try_read+0x4b39/0x72f0 [ 408.072317] Code: c7 c1 20 f0 d4 ae 50 31 d2 48 c7 c6 60 27 d5 ae 48 c7 c7 f8 8e 6f b0 68 60 38 d5 ae e8 00 47 61 fe 48 83 c4 18 e9 ac fc ff ff <0f> 0b e9 06 fe ff ff 4c 8b 9d 98 fd ff ff 0f 84 64 e7 ff ff 89 85 [ 408.072319] RSP: 0018:ffff88811c3e7a30 EFLAGS: 00010246 [ 408.072322] RAX: ffffed1024874c6f RBX: ffffea00042c2b40 RCX: 0000000000000f38 [ 408.072324] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 408.072325] RBP: ffff88811c3e7ca8 R08: 0000000000000000 R09: 00000000000000c8 [ 408.072326] R10: 00000000000000c8 R11: 0000000000000000 R12: 00000000000000c8 [ 408.072327] R13: dffffc0000000000 R14: ffff8881243a6030 R15: 0000000000003000 [ 408.072329] FS: 0000000000000000(0000) GS:ffff88823eadf000(0000) knlGS:0000000000000000 [ 408.072331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 408.072332] CR2: 000000c0003c6000 CR3: 000000010c106005 CR4: 0000000000772ef0 [ 408.072336] PKRU: 55555554 [ 408.072337] Call Trace: [ 408.072338] [ 408.072340] ? sched_clock_noinstr+0x9/0x10 [ 408.072344] ? __pfx_ceph_con_v2_try_read+0x10/0x10 [ 408.072347] ? _raw_spin_unlock+0xe/0x40 [ 408.072349] ? finish_task_switch.isra.0+0x15d/0x830 [ 408.072353] ? __kasan_check_write+0x14/0x30 [ 408.072357] ? mutex_lock+0x84/0xe0 [ 408.072359] ? __pfx_mutex_lock+0x10/0x10 [ 408.072361] ceph_con_workfn+0x27e/0x10e0 [ 408.072364] ? metric_delayed_work+0x311/0x2c50 [ 408.072367] process_one_work+0x611/0xe20 [ 408.072371] ? __kasan_check_write+0x14/0x30 [ 408.072373] worker_thread+0x7e3/0x1580 [ 408.072375] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 408.072378] ? __pfx_worker_thread+0x10/0x10 [ 408.072381] kthread+0x381/0x7a0 [ 408.072383] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 408.072385] ? __pfx_kthread+0x10/0x10 [ 408.072387] ? __kasan_check_write+0x14/0x30 [ 408.072389] ? recalc_sigpending+0x160/0x220 [ 408.072392] ? _raw_spin_unlock_irq+0xe/0x50 [ 408.072394] ? calculate_sigpending+0x78/0xb0 [ 408.072395] ? __pfx_kthread+0x10/0x10 [ 408.072397] ret_from_fork+0x2b6/0x380 [ 408.072400] ? __pfx_kthread+0x10/0x10 [ 408.072402] ret_from_fork_asm+0x1a/0x30 [ 408.072406] [ 408.072407] ---[ end trace 0000000000000000 ]--- [ 408.072418] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68298", "url": "https://ubuntu.com/security/CVE-2025-68298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM) That function can return NULL in some cases. Even when it returns NULL, though, we still go on to call btusb_mtk_claim_iso_intf(). As of commit e9087e828827 (\"Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface()\"), calling btusb_mtk_claim_iso_intf() when `btmtk_data->isopkt_intf` is NULL will cause a crash because we'll end up passing a bad pointer to device_lock(). Prior to that commit we'd pass the NULL pointer directly to usb_driver_claim_interface() which would detect it and return an error, which was handled. Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check at the start of the function. This makes the code handle a NULL `btmtk_data->isopkt_intf` the same way it did before the problematic commit (just with a slight change to the error message printed).", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68339", "url": "https://ubuntu.com/security/CVE-2025-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: atm/fore200e: Fix possible data race in fore200e_open() Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68329", "url": "https://ubuntu.com/security/CVE-2025-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs When a VMA is split (e.g., by partial munmap or MAP_FIXED), the kernel calls vm_ops->close on each portion. For trace buffer mappings, this results in ring_buffer_unmap() being called multiple times while ring_buffer_map() was only called once. This causes ring_buffer_unmap() to return -ENODEV on subsequent calls because user_mapped is already 0, triggering a WARN_ON. Trace buffer mappings cannot support partial mappings because the ring buffer structure requires the complete buffer including the meta page. Fix this by adding a may_split callback that returns -EINVAL to prevent VMA splits entirely.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68330", "url": "https://ubuntu.com/security/CVE-2025-68330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: Fix irq assumption regression The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not.", "cve_priority": "medium", "cve_public_date": "2025-12-22 17:16:00 UTC" }, { "cve": "CVE-2025-68299", "url": "https://ubuntu.com/security/CVE-2025-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with \"afs@\" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68300", "url": "https://ubuntu.com/security/CVE-2025-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/namespace: fix reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns. grab_requested_mnt_ns() doesn't need to take an extra reference.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68301", "url": "https://ubuntu.com/security/CVE-2025-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix fragment overflow handling in RX path The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic. The issue occurs because the driver doesn't check the total number of fragments before calling skb_add_rx_frag(). When a packet requires more than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds. Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path. This crash occurred in production with an Aquantia AQC113 10G NIC. Stack trace from production environment: ``` RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0 Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89 ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90 c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48 89 fa 83 RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287 RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX: fffffffe0a0c8000 RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI: 0000000000037a40 RBP: 0000000000000024 R08: 0000000000000000 R09: 0000000000000021 R10: 0000000000000848 R11: 0000000000000000 R12: ffffa9bec02a8e24 R13: ffff925ad8615570 R14: 0000000000000000 R15: ffff925b22e80a00 FS: 0000000000000000(0000) GS:ffff925e47880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4: 0000000000f72ef0 PKRU: 55555554 Call Trace: aq_ring_rx_clean+0x175/0xe60 [atlantic] ? aq_ring_rx_clean+0x14d/0xe60 [atlantic] ? aq_ring_tx_clean+0xdf/0x190 [atlantic] ? kmem_cache_free+0x348/0x450 ? aq_vec_poll+0x81/0x1d0 [atlantic] ? __napi_poll+0x28/0x1c0 ? net_rx_action+0x337/0x420 ``` Changes in v4: - Add Fixes: tag to satisfy patch validation requirements. Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE, then all fragments are accounted for.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-40290", "url": "https://ubuntu.com/security/CVE-2025-40290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a (\"xsk: Fix immature cq descriptor production\"), the descriptor number is stored in skb control block and xsk_cq_submit_addr_locked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xsk_destruct_skb+0xd0/0x180 [...] Call Trace: ? napi_complete_done+0x7a/0x1a0 ip_rcv_core+0x1bb/0x340 ip_rcv+0x30/0x1f0 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0x87/0x130 __napi_poll+0x28/0x180 net_rx_action+0x339/0x420 handle_softirqs+0xdc/0x320 ? handle_edge_irq+0x90/0x1e0 do_softirq.part.0+0x3b/0x60 __local_bh_enable_ip+0x60/0x70 __dev_direct_xmit+0x14e/0x1f0 __xsk_generic_xmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xsk_generic_xmit+0x51/0xb70 ? _raw_spin_unlock_irqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? __rseq_handle_notify_resume+0xad/0x4c0 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 ? do_syscall_64+0x204/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructor_arg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.", "cve_priority": "medium", "cve_public_date": "2025-12-08 01:16:00 UTC" }, { "cve": "CVE-2025-68302", "url": "https://ubuntu.com/security/CVE-2025-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: fix potential NULL dereference in sxgbe_rx() Currently, when skb is null, the driver prints an error and then dereferences skb on the next line. To fix this, let's add a 'break' after the error message to switch to sxgbe_rx_refill(), which is similar to the approach taken by the other drivers in this particular case, e.g. calxeda with xgmac_rx(). Found during a code review.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68340", "url": "https://ubuntu.com/security/CVE-2025-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68303", "url": "https://ubuntu.com/security/CVE-2025-68303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: intel: punit_ipc: fix memory corruption This passes the address of the pointer \"&punit_ipcdev\" when the intent was to pass the pointer itself \"punit_ipcdev\" (without the ampersand). This means that the: \tcomplete(&ipcdev->cmd_complete); in intel_punit_ioc() will write to a wrong memory address corrupting it.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68341", "url": "https://ubuntu.com/security/CVE-2025-68341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP no_direct return section to fix race As explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing old or uninitialized descriptors\") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested. Prior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.\") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context. Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68304", "url": "https://ubuntu.com/security/CVE-2025-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b (\"Bluetooth: convert conn hash to RCU\") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a (\"Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync\") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68305", "url": "https://ubuntu.com/security/CVE-2025-68305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Prevent race in socket write iter and sock bind There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1]. Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1]. [1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195 Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68306", "url": "https://ubuntu.com/security/CVE-2025-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface When performing reset tests and encountering abnormal card drop issues that lead to a kernel crash, it is necessary to perform a null check before releasing resources to avoid attempting to release a null pointer. <4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT) <4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth] <4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) <4>[ 29.158162] pc : klist_remove+0x90/0x158 <4>[ 29.158174] lr : klist_remove+0x88/0x158 <4>[ 29.158180] sp : ffffffc0846b3c00 <4>[ 29.158185] pmr_save: 000000e0 <4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058 <4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0 <4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290 <4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781 <4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428 <4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018 <4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000 <4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d <4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e <4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c <4>[ 29.158285] Call trace: <4>[ 29.158290] klist_remove+0x90/0x158 <4>[ 29.158298] device_release_driver_internal+0x20c/0x268 <4>[ 29.158308] device_release_driver+0x1c/0x30 <4>[ 29.158316] usb_driver_release_interface+0x70/0x88 <4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)] <4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)] <4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)] <4>[ 29.158430] process_scheduled_works+0x258/0x4e8 <4>[ 29.158441] worker_thread+0x300/0x428 <4>[ 29.158448] kthread+0x108/0x1d0 <4>[ 29.158455] ret_from_fork+0x10/0x20 <0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297) <4>[ 29.158474] ---[ end trace 0000000000000000 ]--- <0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception <2>[ 29.167144] SMP: stopping secondary CPUs <4>[ 29.167158] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68342", "url": "https://ubuntu.com/security/CVE-2025-68342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping). Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received. [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68343", "url": "https://ubuntu.com/security/CVE-2025-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header The driver expects to receive a struct gs_host_frame in gs_usb_receive_bulk_callback(). Use struct_group to describe the header of the struct gs_host_frame and check that we have at least received the header before accessing any members of it. To resubmit the URB, do not dereference the pointer chain \"dev->parent->hf_size_rx\" but use \"parent->hf_size_rx\" instead. Since \"urb->context\" contains \"parent\", it is always defined, while \"dev\" is not defined if the URB it too short.", "cve_priority": "medium", "cve_public_date": "2025-12-23 14:16:00 UTC" }, { "cve": "CVE-2025-68307", "url": "https://ubuntu.com/security/CVE-2025-68307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBs The driver lacks the cleanup of failed transfers of URBs. This reduces the number of available URBs per error by 1. This leads to reduced performance and ultimately to a complete stop of the transmission. If the sending of a bulk URB fails do proper cleanup: - increase netdev stats - mark the echo_sbk as free - free the driver's context and do accounting - wake the send queue", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68308", "url": "https://ubuntu.com/security/CVE-2025-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: leaf: Fix potential infinite loop in command parsers The `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback` functions contain logic to zero-length commands. These commands are used to align data to the USB endpoint's wMaxPacketSize boundary. The driver attempts to skip these placeholders by aligning the buffer position `pos` to the next packet boundary using `round_up()` function. However, if zero-length command is found exactly on a packet boundary (i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up` function will return the unchanged value of `pos`. This prevents `pos` to be increased, causing an infinite loop in the parsing logic. This patch fixes this in the function by using `pos + 1` instead. This ensures that even if `pos` is on a boundary, the calculation is based on `pos + 1`, forcing `round_up()` to always return the next aligned boundary.", "cve_priority": "medium", "cve_public_date": "2025-12-16 16:16:00 UTC" }, { "cve": "CVE-2025-68221", "url": "https://ubuntu.com/security/CVE-2025-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix address removal logic in mptcp_pm_nl_rm_addr Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40246", "url": "https://ubuntu.com/security/CVE-2025-40246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68230", "url": "https://ubuntu.com/security/CVE-2025-68230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gpu page fault after hibernation on PF passthrough On PF passthrough environment, after hibernate and then resume, coralgemm will cause gpu page fault. Mode1 reset happens during hibernate, but partition mode is not restored on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right after resume. When CP access the MQD BO, wrong stride size is used, this will cause out of bound access on the MQD BO, resulting page fault. The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called when resume from a hibernation. KFD resume is called separately during a reset recovery or resume from suspend sequence. Hence it's not required to be called as part of partition switch. (cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68220", "url": "https://ubuntu.com/security/CVE-2025-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 (\"net: ethernet: ti: netcp_core: return error while dma channel open issue\"), but provides a less error prone implementation.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68236", "url": "https://ubuntu.com/security/CVE-2025-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) According to UFS specifications, the power-off sequence for a UFS device includes: - Sending an SSU command with Power_Condition=3 and await a response. - Asserting RST_N low. - Turning off REF_CLK. - Turning off VCC. - Turning off VCCQ/VCCQ2. As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current. This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator. To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode. Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40247", "url": "https://ubuntu.com/security/CVE-2025-40247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix pgtable prealloc error path The following splat was reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT Tainted: [S]=CPU_OUT_OF_SPEC Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT) pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : build_detached_freelist+0x28/0x224 lr : kmem_cache_free_bulk.part.0+0x38/0x244 sp : ffff000a508c7a20 x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350 x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000 x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000 x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8 x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640 x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30 x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940 x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000 x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8 x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00 Call trace: build_detached_freelist+0x28/0x224 (P) kmem_cache_free_bulk.part.0+0x38/0x244 kmem_cache_free_bulk+0x10/0x1c msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0 msm_vma_job_free+0x30/0x240 msm_ioctl_vm_bind+0x1d0/0x9a0 drm_ioctl_kernel+0x84/0x104 drm_ioctl+0x358/0x4d4 __arm64_sys_ioctl+0x8c/0xe0 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x3c/0xe0 do_el0_svc+0x18/0x20 el0_svc+0x30/0x100 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x170/0x174 Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6) ---[ end trace 0000000000000000 ]--- Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue. Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call. So handle that case better. Patchwork: https://patchwork.freedesktop.org/patch/678677/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40248", "url": "https://ubuntu.com/security/CVE-2025-40248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Ignore signal/timeout on connect() if already established During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues: 1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling. 2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs. 3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref. Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg(). [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68219", "url": "https://ubuntu.com/security/CVE-2025-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: fix memory leak in smb3_fs_context_parse_param error path Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues. This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed. The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak. This issue was not addressed by commit e8c73eb7db0a (\"cifs: client: fix memory leak in smb3_fs_context_parse_param\"), which only fixed leaks from repeated fsconfig() calls but not this error path. Patch updated with minor change suggested by kernel test robot", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40249", "url": "https://ubuntu.com/security/CVE-2025-40249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: cdev: make sure the cdev fd is still active before emitting events With the final call to fput() on a file descriptor, the release action may be deferred and scheduled on a work queue. The reference count of that descriptor is still zero and it must not be used. It's possible that a GPIO change, we want to notify the user-space about, happens AFTER the reference count on the file descriptor associated with the character device went down to zero but BEFORE the .release() callback was called from the workqueue and so BEFORE we unregistered from the notifier. Using the regular get_file() routine in this situation triggers the following warning: struct file::f_count incremented from zero; use-after-free condition present! So use the get_file_active() variant that will return NULL on file descriptors that have been or are being released.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40250", "url": "https://ubuntu.com/security/CVE-2025-40250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clean up only new IRQ glue on request_irq() failure The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added. This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object. Note: This error is observed when both fwctl and rds configs are enabled. [1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40251", "url": "https://ubuntu.com/security/CVE-2025-40251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: devlink: rate: Unset parent pointer in devl_rate_nodes_destroy The function devl_rate_nodes_destroy is documented to \"Unset parent for all rate objects\". However, it was only calling the driver-specific `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing the parent's refcount, without actually setting the `devlink_rate->parent` pointer to NULL. This leaves a dangling pointer in the `devlink_rate` struct, which cause refcount error in netdevsim[1] and mlx5[2]. In addition, this is inconsistent with the behavior of `devlink_nl_rate_parent_node_set`, where the parent pointer is correctly cleared. This patch fixes the issue by explicitly setting `devlink_rate->parent` to NULL after notifying the driver, thus fulfilling the function's documented behavior for all rate objects. [1] repro steps: echo 1 > /sys/bus/netdevsim/new_device devlink dev eswitch set netdevsim/netdevsim1 mode switchdev echo 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs devlink port function rate add netdevsim/netdevsim1/test_node devlink port function rate set netdevsim/netdevsim1/128 parent test_node echo 1 > /sys/bus/netdevsim/del_device dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] devlink dev eswitch set pci/0000:08:00.0 mode switchdev devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000 devlink port function rate add pci/0000:08:00.0/group1 devlink port function rate set pci/0000:08:00.0/32768 parent group1 modprobe -r mlx5_ib mlx5_fwctl mlx5_core dmesg: refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0 CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:refcount_warn_saturate+0x42/0xe0 Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68222", "url": "https://ubuntu.com/security/CVE-2025-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its fields are initialized. Notably, num_custom_params is used in pinconf_generic_parse_dt_config(), resulting in intermittent allocation errors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...] This results in later parse failures that can cause issues in dependent drivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registered Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of devm_kmalloc() in s32_pinctrl_probe(), which sets the previously uninitialized fields to zero.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68215", "url": "https://ubuntu.com/security/CVE-2025-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix PTP cleanup on driver removal in error path Improve the cleanup on releasing PTP resources in error path. The error case might happen either at the driver probe and PTP feature initialization or on PTP restart (errors in reset handling, NVM update etc). In both cases, calls to PF PTP cleanup (ice_ptp_cleanup_pf function) and 'ps_lock' mutex deinitialization were missed. Additionally, ptp clock was not unregistered in the latter case. Keep PTP state as 'uninitialized' on init to distinguish between error scenarios and to avoid resource release duplication at driver removal. The consequence of missing ice_ptp_cleanup_pf call is the following call trace dumped when ice_adapter object is freed (port list is not empty, as it is required at this stage): [ T93022] ------------[ cut here ]------------ [ T93022] WARNING: CPU: 10 PID: 93022 at ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice] ... [ T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice] ... [ T93022] Call Trace: [ T93022] [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? __warn.cold+0xb0/0x10e [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] ? report_bug+0xd8/0x150 [ T93022] ? handle_bug+0xe9/0x110 [ T93022] ? exc_invalid_op+0x17/0x70 [ T93022] ? asm_exc_invalid_op+0x1a/0x20 [ T93022] ? ice_adapter_put+0xef/0x100 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] [ T93022] pci_device_remove+0x42/0xb0 [ T93022] device_release_driver_internal+0x19f/0x200 [ T93022] driver_detach+0x48/0x90 [ T93022] bus_remove_driver+0x70/0xf0 [ T93022] pci_unregister_driver+0x42/0xb0 [ T93022] ice_module_exit+0x10/0xdb0 [ice 33d2647ad4f6d866d41eefff1806df37c68aef0c] ... [ T93022] ---[ end trace 0000000000000000 ]--- [ T93022] ice: module unloaded", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68213", "url": "https://ubuntu.com/security/CVE-2025-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix possible vport_config NULL pointer deref in remove Attempting to remove the driver will cause a crash in cases where the vport failed to initialize. Following trace is from an instance where the driver failed during an attempt to create a VF: [ 1661.543624] idpf 0000:84:00.7: Device HW Reset initiated [ 1722.923726] idpf 0000:84:00.7: Transaction timed-out (op:1 cookie:2900 vc_op:1 salt:29 timeout:60000ms) [ 1723.353263] BUG: kernel NULL pointer dereference, address: 0000000000000028 ... [ 1723.358472] RIP: 0010:idpf_remove+0x11c/0x200 [idpf] ... [ 1723.364973] Call Trace: [ 1723.365475] [ 1723.365972] pci_device_remove+0x42/0xb0 [ 1723.366481] device_release_driver_internal+0x1a9/0x210 [ 1723.366987] pci_stop_bus_device+0x6d/0x90 [ 1723.367488] pci_stop_and_remove_bus_device+0x12/0x20 [ 1723.367971] pci_iov_remove_virtfn+0xbd/0x120 [ 1723.368309] sriov_disable+0x34/0xe0 [ 1723.368643] idpf_sriov_configure+0x58/0x140 [idpf] [ 1723.368982] sriov_numvfs_store+0xda/0x1c0 Avoid the NULL pointer dereference by adding NULL pointer check for vport_config[i], before freeing user_config.q_coalesce.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40252", "url": "https://ubuntu.com/security/CVE-2025-40252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end() The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array. Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40253", "url": "https://ubuntu.com/security/CVE-2025-40253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/ctcm: Fix double-kfree The function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionally from function 'ctcmpc_unpack_skb'. It frees passed mpcginfo. After that a call to function 'kfree' in function 'ctcmpc_unpack_skb' frees it again. Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'. Bug detected by the clang static analyzer.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68218", "url": "https://ubuntu.com/security/CVE-2025-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix lockdep WARN due to partition scan work Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion. To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68232", "url": "https://ubuntu.com/security/CVE-2025-68232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: veth: more robust handing of race to avoid txq getting stuck Commit dc82a33297fc (\"veth: apply qdisc backpressure on full ptr_ring to reduce TX drops\") introduced a race condition that can lead to a permanently stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra Max). The race occurs in veth_xmit(). The producer observes a full ptr_ring and stops the queue (netif_tx_stop_queue()). The subsequent conditional logic, intended to re-wake the queue if the consumer had just emptied it (if (__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a \"lost wakeup\" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and traffic halts. This failure is caused by an incorrect use of the __ptr_ring_empty() API from the producer side. As noted in kernel comments, this check is not guaranteed to be correct if a consumer is operating on another CPU. The empty test is based on ptr_ring->consumer_head, making it reliable only for the consumer. Using this check from the producer side is fundamentally racy. This patch fixes the race by adopting the more robust logic from an earlier version V4 of the patchset, which always flushed the peer: (1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier are removed. Instead, after stopping the queue, we unconditionally call __veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled, making it solely responsible for re-waking the TXQ. This handles the race where veth_poll() consumes all packets and completes NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue. The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule NAPI. (2) On the consumer side, the logic for waking the peer TXQ is moved out of veth_xdp_rcv() and placed at the end of the veth_poll() function. This placement is part of fixing the race, as the netif_tx_queue_stopped() check must occur after rx_notify_masked is potentially set to false during NAPI completion. This handles the race where veth_poll() consumes all packets, but haven't finished (rx_notify_masked is still true). The producer veth_xmit() stops the TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning not starting NAPI. Then veth_poll() change rx_notify_masked to false and stops NAPI. Before exiting veth_poll() will observe TXQ is stopped and wake it up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40254", "url": "https://ubuntu.com/security/CVE-2025-40254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: remove never-working support for setting nsh fields The validation of the set(nsh(...)) action is completely wrong. It runs through the nsh_key_put_from_nlattr() function that is the same function that validates NSH keys for the flow match and the push_nsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible. There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'is_mask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SW_FLOW_KEY_PUT() during validation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The third issue with this process is that while trying to convert the non-masked set into masked one, validate_set() copies and doubles the size of the OVS_KEY_ATTR_NSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump. In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up. Fixing all the issues is a complex task as it requires re-writing most of the validation code. Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68233", "url": "https://ubuntu.com/security/CVE-2025-68233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Add call to put_pid() Add a call to put_pid() corresponding to get_task_pid(). host1x_memory_context_alloc() does not take ownership of the PID so we need to free it here to avoid leaking. [mperttunen@nvidia.com: reword commit message]", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40255", "url": "https://ubuntu.com/security/CVE-2025-40255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower() The ethtool tsconfig Netlink path can trigger a null pointer dereference. A call chain such as: tsconfig_prepare_data() -> dev_get_hwtstamp_phylib() -> vlan_hwtstamp_get() -> generic_hwtstamp_get_lower() -> generic_hwtstamp_ioctl_lower() results in generic_hwtstamp_ioctl_lower() being called with kernel_cfg->ifr as NULL. The generic_hwtstamp_ioctl_lower() function does not expect a NULL ifr and dereferences it, leading to a system crash. Fix this by adding a NULL check for kernel_cfg->ifr in generic_hwtstamp_ioctl_lower(). If ifr is NULL, return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68228", "url": "https://ubuntu.com/security/CVE-2025-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/plane: Fix create_in_format_blob() return value create_in_format_blob() is either supposed to return a valid pointer or an error, but never NULL. The caller will dereference the blob when it is not an error, and thus will oops if NULL returned. Return proper error values in the failure cases.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68223", "url": "https://ubuntu.com/security/CVE-2025-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock. dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable. (cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40257", "url": "https://ubuntu.com/security/CVE-2025-40257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix a race in mptcp_pm_del_add_timer() mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer) while another might have free entry already, as reported by syzbot. Add RCU protection to fix this issue. Also change confusing add_timer variable with stop_timer boolean. syzbot report: BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44 CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Workqueue: events mptcp_worker Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40258", "url": "https://ubuntu.com/security/CVE-2025-40258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race condition in mptcp_schedule_work() syzbot reported use-after-free in mptcp_schedule_work() [1] Issue here is that mptcp_schedule_work() schedules a work, then gets a refcount on sk->sk_refcnt if the work was scheduled. This refcount will be released by mptcp_worker(). [A] if (schedule_work(...)) { [B] sock_hold(sk); return true; } Problem is that mptcp_worker() can run immediately and complete before [B] We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk); [1] refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68216", "url": "https://ubuntu.com/security/CVE-2025-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Disable trampoline for kernel module function trace The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68229", "url": "https://ubuntu.com/security/CVE-2025-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40259", "url": "https://ubuntu.com/security/CVE-2025-40259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Do not sleep in atomic context sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40260", "url": "https://ubuntu.com/security/CVE-2025-40260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix scx_enable() crash on helper kthread creation failure A crash was observed when the sched_ext selftests runner was terminated with Ctrl+\\ while test 15 was running: NIP [c00000000028fa58] scx_enable.constprop.0+0x358/0x12b0 LR [c00000000028fa2c] scx_enable.constprop.0+0x32c/0x12b0 Call Trace: scx_enable.constprop.0+0x32c/0x12b0 (unreliable) bpf_struct_ops_link_create+0x18c/0x22c __sys_bpf+0x23f8/0x3044 sys_bpf+0x2c/0x6c system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec kthread_run_worker() returns an ERR_PTR() on failure rather than NULL, but the current code in scx_alloc_and_add_sched() only checks for a NULL helper. Incase of failure on SIGQUIT, the error is not handled in scx_alloc_and_add_sched() and scx_enable() ends up dereferencing an error pointer. Error handling is fixed in scx_alloc_and_add_sched() to propagate PTR_ERR() into ret, so that scx_enable() jumps to the existing error path, avoiding random dereference on failure.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40261", "url": "https://ubuntu.com/security/CVE-2025-40261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur: [ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] ", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68235", "url": "https://ubuntu.com/security/CVE-2025-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a kmemleak warning. Make sure this data is deallocated.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68231", "url": "https://ubuntu.com/security/CVE-2025-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mempool: fix poisoning order>0 pages with HIGHMEM The kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283) Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed. We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68217", "url": "https://ubuntu.com/security/CVE-2025-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: pegasus-notetaker - fix potential out-of-bounds access In the pegasus_notetaker driver, the pegasus_probe() function allocates the URB transfer buffer using the wMaxPacketSize value from the endpoint descriptor. An attacker can use a malicious USB descriptor to force the allocation of a very small buffer. Subsequently, if the device sends an interrupt packet with a specific pattern (e.g., where the first byte is 0x80 or 0x42), the pegasus_parse_packet() function parses the packet without checking the allocated buffer size. This leads to an out-of-bounds memory access.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40262", "url": "https://ubuntu.com/security/CVE-2025-40262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: imx_sc_key - fix memory corruption on unload This is supposed to be \"priv\" but we accidentally pass \"&priv\" which is an address in the stack and so it will lead to memory corruption when the imx_sc_key_action() function is called. Remove the &.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-40263", "url": "https://ubuntu.com/security/CVE-2025-40263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: cros_ec_keyb - fix an invalid memory access If cros_ec_keyb_register_matrix() isn't called (due to `buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains NULL. An invalid memory access is observed in cros_ec_keyb_process() when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_thread It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access `ckdev->idev` and friends if the driver doesn't intend to initialize them.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68234", "url": "https://ubuntu.com/security/CVE-2025-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/cmd_net: fix wrong argument types for skb_queue_splice() If timestamp retriving needs to be retried and the local list of SKB's already has entries, then it's spliced back into the socket queue. However, the arguments for the splice helper are transposed, causing exactly the wrong direction of splicing into the on-stack list. Fix that up.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40264", "url": "https://ubuntu.com/security/CVE-2025-40264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: pass wrb_params in case of OS2BMC be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site.  This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb (\"be2net: fix a Tx stall bug caused by a specific ipv6 packet\") states. The correct way would be to pass the wrb_params from be_xmit().", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68225", "url": "https://ubuntu.com/security/CVE-2025-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/test_kho: check if KHO is enabled We must check whether KHO is enabled prior to issuing KHO commands, otherwise KHO internal data structures are not initialized.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68227", "url": "https://ubuntu.com/security/CVE-2025-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: Fix proto fallback detection with BPF The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \\ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68237", "url": "https://ubuntu.com/security/CVE-2025-68237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtdchar: fix integer overflow in read/write ioctls The \"req.start\" and \"req.len\" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of \"req.len\" so that's capped at U32_MAX but the \"req.start\" variable can go up to U64_MAX which means that the addition can still integer overflow. Use check_add_overflow() to fix this bug.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68212", "url": "https://ubuntu.com/security/CVE-2025-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized 'offp' in statmount_string() In statmount_string(), most flags assign an output offset pointer (offp) which is later updated with the string offset. However, the STATMOUNT_MNT_UIDMAP and STATMOUNT_MNT_GIDMAP cases directly set the struct fields instead of using offp. This leaves offp uninitialized, leading to a possible uninitialized dereference when *offp is updated. Fix it by assigning offp for UIDMAP and GIDMAP as well, keeping the code path consistent.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-68238", "url": "https://ubuntu.com/security/CVE-2025-68238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix DMA device NULL pointer dereference The DMA device pointer `dma_dev` was being dereferenced before ensuring that `cdns_ctrl->dmac` is properly initialized. Move the assignment of `dma_dev` after successfully acquiring the DMA channel to ensure the pointer is valid before use.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40265", "url": "https://ubuntu.com/security/CVE-2025-40265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfat: fix missing sb_min_blocksize() return value checks When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: ---truncated---", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" }, { "cve": "CVE-2025-68214", "url": "https://ubuntu.com/security/CVE-2025-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: timers: Fix NULL function pointer race in timer_shutdown_sync() There is a race condition between timer_shutdown_sync() and timer expiration that can lead to hitting a WARN_ON in expire_timers(). The issue occurs when timer_shutdown_sync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this: CPU0\t\t\t\t\tCPU1 \t\t\t\t\t \t\t\t\t\tlock_timer_base() \t\t\t\t\texpire_timers() \t\t\t\t\tbase->running_timer = timer; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t[call_timer_fn enter] \t\t\t\t\tmod_timer() \t\t\t\t\t... timer_shutdown_sync() lock_timer_base() // For now, will not detach the timer but only clear its function to NULL if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() \t\t\t\t\t[call_timer_fn exit] \t\t\t\t\tlock_timer_base() \t\t\t\t\tbase->running_timer = NULL; \t\t\t\t\tunlock_timer_base() \t\t\t\t\t... \t\t\t\t\t// Now timer is pending while its function set to NULL. \t\t\t\t\t// next timer trigger \t\t\t\t\t \t\t\t\t\texpire_timers() \t\t\t\t\tWARN_ON_ONCE(!fn) // hit \t\t\t\t\t... lock_timer_base() // Now timer will detach if (base->running_timer != timer) \tret = detach_if_pending(timer, base, true); if (shutdown) \ttimer->function = NULL; unlock_timer_base() The problem is that timer_shutdown_sync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARN_ON_ONCE(!fn) check in expire_timers(). Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.", "cve_priority": "medium", "cve_public_date": "2025-12-16 14:15:00 UTC" }, { "cve": "CVE-2025-40266", "url": "https://ubuntu.com/security/CVE-2025-40266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Check the untrusted offset in FF-A memory share Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.", "cve_priority": "medium", "cve_public_date": "2025-12-04 16:16:00 UTC" } ], "log": [ "", " * noble/linux-riscv-6.17: 6.17.0-16.16.1~24.04.1 -proposed tracker (LP: #2141143)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv-6.17/dkms-versions -- update from kernel-", " versions (main/2026.02.09)", "", " [ Ubuntu-riscv: 6.17.0-16.16.1 ]", "", " * questing/linux-riscv: 6.17.0-16.16.1 -proposed tracker (LP: #2141144)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.riscv/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " [ Ubuntu: 6.17.0-16.16 ]", " * questing/linux: 6.17.0-16.16 -proposed tracker (LP: #2141148)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.02.09)", " * Support Intel Scorpius Peak, Whale Peak WiFi/Bluetooth for Intel Panther", " Lake platforms (LP: #2116169)", " - Bluetooth: btintel_pcie: Add Bluetooth core/platform as comments", " - Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484", " * Boot up hang with ucsi call trace while plug power cord or device on tbt5", " port (LP: #2127764)", " - SAUCE: usb: typec: ucsi: Fix workqueue destruction race during connector", " cleanup", " * net:rtnetlink.sh in ubuntu_kernel_selftests failed with FAIL: address", " proto IPv4 / IPv6 (LP: #2031531)", " - selftests: rtnetlink: skip tests if tools or feats are missing", " * TBT call trace while connecting TBT4 monitor on TBT5 port (LP: #2137613)", " - drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WA", " * No output on external monitor when connecting to dell dock (LP: #2131066)", " - drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC", " - drm/i915/dp: Ensure the FEC state stays disabled for UHBR links", " - drm/i915/dp: Export helper to determine if FEC on non-UHBR links is", " required", " - drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config", " - drm/i915/dp_mst: Track DSC enabled status on the MST link", " - drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the", " link", " - drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed", " vblank", " - drm/i915/display: Remove unused declarations of intel_io_*", " - drm/i915/dp: Fix panel replay when DSC is enabled", " * [questing] kernel BUG at lib/string_helpers.c:1043! (LP: #2129580)", " - erspan: Initialize options_len before referencing options.", " * Hotplug dock with monitor leads to call trace (LP: #2130998)", " - drm/i915/psr: Check pause counter before continuing to PSR activation", " - drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_locked", " * [SRU] Fix the error during suspend on cs42l43 (LP: #2138423)", " - mfd: cs42l43: Remove IRQ masking in suspend", " - ASoC: cs42l43: Rename system suspend callback and fix debug print", " - ASoC: cs42l43: Store IRQ domain in codec private data", " - ASoC: cs42l43: Disable IRQs in system suspend", " - ASoC: cs42l43: Shutdown jack detection on suspend", " * noble/plucky: ubuntu_kselftests_ftrace fails 7 ftrace:test.d tests for", " riscv64 on openstack:riscv64.vm (LP: #2124276)", " - riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG", " - [Config] Enable ARCH_HAVE_NMI_SAFE_CMPXCHG for riscv64", " * Got call trace when plug in device/AC in type-c port(both TBT5/TBT4)", " (LP: #2138192)", " - usb: typec: ucsi: Add support for READ_POWER_LEVEL command", " - usb: typec: ucsi: Add check for UCSI version", " * Export CWSR size to userspace (LP: #2134491)", " - drm/amdkfd: bump minimum vgpr size for gfx1151", " - drm/amdkfd: Export the cwsr_size and ctl_stack_size to userspace", " * [SRU] add pmc c6 support of Arrow Lake (LP: #2137615)", " - platform/x86:intel/pmc: Update Arrow Lake telemetry GUID", " - platform/x86:intel/pmc: Add support for multiple DMU GUIDs", " - platform/x86:intel/pmc: Add DMU GUID to Arrow Lake U/H", " * net:tap in ubuntu_kselftests_net fails on Noble (buffer overflow detected)", " (LP: #2067642)", " - SAUCE: selftests: net: fix \"buffer overflow detected\" for tap.c", " * MT7925 wifi is hard blocked on HP's machine (LP: #2127044)", " - SAUCE: wifi: mt76: mt7925: add DMI quirk for HP Z2 Mini G1a Workstation", " * No on-screen keyboard on dell tablets (LP: #2122398)", " - platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI", " quirks", " * Enable RTL ASPM for more new Dell platforms (LP: #2133144)", " - SAUCE: r8169: Add more Dell platforms to enable ASPM", " * Enable RTL ASPM for new Dell platforms (LP: #2121200)", " - SAUCE: r8169: enable ASPM on all new Dell platforms", " * Questing update: v6.17.13 upstream stable release (LP: #2139960)", " - smack: deduplicate \"does access rule request transmutation\"", " - smack: fix bug: SMACK64TRANSMUTE set on non-directory", " - smack: deduplicate xattr setting in smack_inode_init_security()", " - smack: always \"instantiate\" inode in smack_inode_init_security()", " - smack: fix bug: invalid label of unix socket file", " - smack: fix bug: setting task label silently ignores input garbage", " - accel/ivpu: Ensure rpm_runtime_put in case of engine reset/resume fail", " - drm/panel: visionox-rm69299: Fix clock frequency for SHIFT6mq", " - drm/panel: visionox-rm69299: Don't clear all mode flags", " - accel/ivpu: Rework bind/unbind of imported buffers", " - accel/ivpu: Make function parameter names consistent", " - accel/ivpu: Fix DCT active percent format", " - bpf: Cleanup unused func args in rqspinlock implementation", " - tools/nolibc: handle NULL wstatus argument to waitpid()", " - USB: Fix descriptor count when handling invalid MBIM extended descriptor", " - perf bpf_counter: Fix opening of \"any\"(-1) CPU events", " - ima: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook", " - pinctrl: renesas: rzg2l: Fix PMC restore", " - clk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callback", " - clk: renesas: cpg-mssr: Read back reset registers to assure values", " latched", " - drm: atmel-hlcdc: fix atmel_xlcdc_plane_setup_scaler()", " - HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()", " - remoteproc: imx_rproc: Fix runtime PM cleanup and improve remove path", " - objtool: Fix standalone --hacks=jump_label", " - objtool: Fix weak symbol detection", " - accel/ivpu: Fix race condition when mapping dmabuf", " - perf parse-events: Fix legacy cache events if event is duplicated in a", " PMU", " - wifi: ath10k: move recovery check logic into a new work", " - wifi: ath11k: restore register window after global reset", " - wifi: ath12k: fix VHT MCS assignment", " - wifi: ath12k: fix TX and RX MCS rate configurations in HE mode", " - sched/fair: Forfeit vruntime on yield", " - irqchip/bcm2712-mip: Fix OF node reference imbalance", " - irqchip/bcm2712-mip: Fix section mismatch", " - irqchip/irq-bcm7038-l1: Fix section mismatch", " - irqchip/irq-bcm7120-l2: Fix section mismatch", " - irqchip/irq-brcmstb-l2: Fix section mismatch", " - irqchip/imx-mu-msi: Fix section mismatch", " - irqchip/renesas-rzg2l: Fix section mismatch", " - irqchip/starfive-jh8100: Fix section mismatch", " - irqchip/qcom-irq-combiner: Fix section mismatch", " - crypto: authenc - Correctly pass EINPROGRESS back up to the caller", " - dt-bindings: clock: qcom,x1e80100-gcc: Add missing USB4 clocks/resets", " - clk: qcom: gcc-x1e80100: Add missing USB4 clocks/resets", " - rculist: Add hlist_nulls_replace_rcu() and", " hlist_nulls_replace_init_rcu()", " - inet: Avoid ehash lookup race in inet_ehash_insert()", " - inet: Avoid ehash lookup race in inet_twsk_hashdance_schedule()", " - iio: imu: st_lsm6dsx: Fix measurement unit for odr struct member", " - firmware: qcom: tzmem: fix qcom_tzmem_policy kernel-doc", " - block/mq-deadline: Introduce dd_start_request()", " - block/mq-deadline: Switch back to a single dispatch list", " - arm64: dts: freescale: imx8mp-venice-gw7905-2x: remove duplicate usdhc1", " props", " - arm64: dts: imx8mm-venice-gw72xx: remove unused sdhc1 pinctrl", " - arm64: dts: imx8mp-venice-gw702x: remove off-board uart", " - arm64: dts: imx8mp-venice-gw702x: remove off-board sdhc1", " - arm64: dts: imx95-15x15-evk: add fan-supply property for pwm-fan", " - perf annotate: Check return value of evsel__get_arch() properly", " - arm64: dts: exynos: gs101: fix sysreg_apm reg property", " - PCI: rcar-gen2: Drop ARM dependency from PCI_RCAR_GEN2", " - uio: uio_fsl_elbc_gpcm:: Add null pointer check to", " uio_fsl_elbc_gpcm_probe", " - tty: introduce tty_port_tty guard()", " - tty: serial: imx: Only configure the wake register when device is set as", " wakeup source", " - clk: qcom: camcc-sm8550: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to", " other", " - clk: qcom: gcc-sm8750: Add a new frequency for sdcc2 clock", " - clk: qcom: gcc-ipq5424: Correct the icc_first_node_id", " - clk: qcom: camcc-sm6350: Fix PLL config of PLL2", " - clk: qcom: camcc-sm7150: Fix PLL config of PLL2", " - soc: qcom: gsbi: fix double disable caused by devm", " - crypto: hisilicon/qm - restore original qos values", " - wifi: ath11k: fix VHT MCS assignment", " - s390/smp: Fix fallback CPU detection", " - scsi: ufs: core: Move the ufshcd_enable_intr() declaration", " - s390/ap: Don't leak debug feature files if AP instructions are not", " available", " - tools/power turbostat: Regression fix Uncore MHz printed in hex", " - wifi: ath12k: restore register window after global reset", " - leds: upboard: Fix module alias", " - PCI: endpoint: pci-epf-test: Fix sleeping function being called from", " atomic context", " - arm64: dts: ti: k3-am62p: Fix memory ranges for GPU", " - firmware: imx: scu-irq: fix OF node leak in", " - arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller", " - arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller", " - arm64: dts: qcom: sdm845-starqltechn: remove (address|size)-cells", " - arm64: dts: qcom: starqltechn: remove extra empty line", " - arm64: dts: qcom: sdm845-starqltechn: fix max77705 interrupts", " - arm64: dts: qcom: sdm845-oneplus: Correct gpio used for slider", " - arm64: dts: qcom: qcm6490-fairphone-fp5: Add supplies to simple-fb node", " - arm64: dts: qcom: sm8650: set ufs as dma coherent", " - arm64: dts: qcom: qcm6490-shift-otter: Add missing reserved-memory", " - arm64: dts: qcom: sdm845-starqltechn: Fix i2c-gpio node name", " - perf hwmon_pmu: Fix uninitialized variable warning", " - phy: mscc: Fix PTP for VSC8574 and VSC8572", " - sctp: Defer SCTP_DBG_OBJCNT_DEC() to sctp_destroy_sock().", " - arm64: dts: qcom: qcm2290: Add CCI node", " - arm64: dts: qcom: qcm2290: Fix camss register prop ordering", " - ARM: dts: renesas: gose: Remove superfluous port property", " - ARM: dts: renesas: r9a06g032-rzn1d400-db: Drop invalid #cells properties", " - drm/amdgpu: add userq object va track helpers", " - drm/amdgpu/userq: fix SDMA and compute validation", " - wifi: iwlwifi: mld: add null check for kzalloc() in", " iwl_mld_send_proto_offload()", " - Revert \"mtd: rawnand: marvell: fix layouts\"", " - mtd: nand: relax ECC parameter validation check", " - mtd: rawnand: lpc32xx_slc: fix GPIO descriptor leak on probe error and", " remove", " - perf: Remove get_perf_callchain() init_nr argument", " - bpf: Refactor stack map trace depth calculation into helper function", " - perf/x86/intel/cstate: Remove PC3 support from LunarLake", " - task_work: Fix NMI race condition", " - x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()", " - accel/ivpu: Remove skip of dma unmap for imported buffers", " - tools/nolibc/stdio: let perror work when NOLIBC_IGNORE_ERRNO is set", " - tools/nolibc/dirent: avoid errno in readdir_r", " - clk: qcom: gcc-qcs615: Update the SDCC clock to use shared_floor_ops", " - soc: qcom: smem: fix hwspinlock resource leak in probe error paths", " - pinctrl: stm32: fix hwspinlock resource leak in probe function", " - drm: nova: select NOVA_CORE", " - [Config] select NOVA_CORE", " - gpu: nova-core: select RUST_FW_LOADER_ABSTRACTIONS", " - pidfs: add missing PIDFD_INFO_SIZE_VER1", " - pidfs: add missing BUILD_BUG_ON() assert on struct pidfd_info", " - i3c: fix refcount inconsistency in i3c_master_register", " - i3c: master: svc: Prevent incomplete IBI transaction", " - random: use offstack cpumask when necessary", " - wifi: ath12k: fix potential memory leak in ath12k_wow_arp_ns_offload()", " - wifi: ath12k: fix reusing m3 memory", " - wifi: ath12k: fix error handling in creating hardware group", " - wifi: ath12k: unassign arvif on scan vdev create failure", " - interconnect: qcom: msm8996: add missing link to SLAVE_USB_HS", " - arm64: dts: qcom: msm8996: add interconnect paths to USB2 controller", " - accel/amdxdna: Fix incorrect command state for timed out job", " - interconnect: debugfs: Fix incorrect error handling for NULL path", " - arm64: dts: renesas: sparrow-hawk: Fix full-size DP connector node name", " and labels", " - drm/imagination: Fix reference to", " devm_platform_get_and_ioremap_resource()", " - perf lock contention: Load kernel map before lookup", " - perf record: skip synthesize event when open evsel failed", " - timers/migration: Convert \"while\" loops to use \"for\"", " - timers/migration: Remove locking on group connection", " - timers/migration: Fix imbalanced NUMA trees", " - power: supply: rt5033_charger: Fix device node reference leaks", " - power: supply: cw2015: Check devm_delayed_work_autocancel() return code", " - power: supply: max17040: Check iio_read_channel_processed() return code", " - power: supply: rt9467: Return error on failure in", " rt9467_set_value_from_ranges()", " - power: supply: rt9467: Prevent using uninitialized local variable in", " rt9467_set_value_from_ranges()", " - power: supply: wm831x: Check wm831x_set_bits() return value", " - power: supply: apm_power: only unset own apm_get_power_status", " - scsi: target: Do not write NUL characters into ASCII configfs output", " - scsi: target: Fix LUN/device R/W and total command stats", " - fs/9p: Don't open remote file with APPEND mode when writeback cache is", " used", " - drm/panthor: Handle errors returned by drm_sched_entity_init()", " - drm/panthor: Fix group_free_queue() for partially initialized queues", " - drm/panthor: Fix race with suspend during unplug", " - firmware: ti_sci: Set IO Isolation only if the firmware is capable", " - cleanup: fix scoped_class()", " - libbpf: Fix parsing of multi-split BTF", " - ARM: dts: am335x-netcom-plus-2xx: add missing GPIO labels", " - ARM: dts: omap3: beagle-xm: Correct obsolete TWL4030 power compatible", " - ARM: dts: omap3: n900: Correct obsolete TWL4030 power compatible", " - entry,unwind/deferred: Fix unwind_reset_info() placement", " - x86/boot: Fix page table access in 5-level to 4-level paging transition", " - efi/libstub: Fix page table access in 5-level to 4-level paging", " transition", " - locktorture: Fix memory leak in param_set_cpumask()", " - wifi: rtw89: usb: use common error path for skbs in", " rtw89_usb_rx_handler()", " - wifi: rtw89: usb: fix leak in rtw89_usb_write_port()", " - mfd: da9055: Fix missing regmap_del_irq_chip() in error path", " - wifi: ath12k: Fix timeout error during beacon stats retrieval", " - ext4: correct the checking of quota files before moving extents", " - accel/amdxdna: Fix dma_fence leak when job is canceled", " - io_uring: use WRITE_ONCE for user shared memory", " - perf/x86/intel: Correct large PEBS flag check", " - regulator: core: disable supply if enabling main regulator fails", " - md: delete mddev kobj before deleting gendisk kobj", " - scsi: stex: Fix reboot_notifier leak in probe error path", " - [Config] remove most i2c driver", " - iio: imu: bmi270: fix dev_err_probe error msg", " - dt-bindings: PCI: amlogic: Fix the register name of the DBI region", " - RDMA/rtrs: server: Fix error handling in get_or_create_srv", " - ARM: dts: stm32: stm32mp157c-phycore: Fix STMPE811 touchscreen node", " properties", " - drm/panthor: Fix potential memleak of vma structure", " - scsi: ufs: core: fix incorrect buffer duplication in", " ufshcd_read_string_desc()", " - md: delete md_redundancy_group when array is becoming inactive", " - cpufreq/amd-pstate: Call cppc_set_auto_sel() only for online CPUs", " - powerpc/kdump: Fix size calculation for hot-removed memory ranges", " - powerpc/32: Fix unpaired stwcx. on interrupt exit", " - wifi: cw1200: Fix potential memory leak in cw1200_bh_rx_helper()", " - coresight: Change device mode to atomic type", " - coresight: etm4x: Always set tracer's device mode on target CPU", " - coresight: etm3x: Always set tracer's device mode on target CPU", " - coresight: etm4x: Correct polling IDLE bit", " - coresight: etm4x: Add context synchronization before enabling trace", " - coresight: etm4x: Properly control filter in CPU idle with FEAT_TRF", " - perf tools: Fix missing feature check for inherit + SAMPLE_READ", " - drm/tidss: Remove max_pclk_khz and min_pclk_khz from tidss display", " features", " - drm/tidss: Move OLDI mode validation to OLDI bridge mode_valid hook", " - clk: renesas: r9a09g077: Propagate rate changes to parent clocks", " - clk: renesas: r9a06g032: Fix memory leak in error path", " - lib/vsprintf: Check pointer before dereferencing in time_and_date()", " - ocfs2: use correct endian in ocfs2_dinode_has_extents", " - ACPI: property: Fix fwnode refcount leak in", " acpi_fwnode_graph_parse_endpoint()", " - scsi: sim710: Fix resource leak by adding missing ioport_unmap() calls", " - leds: netxbig: Fix GPIO descriptor leak in error paths", " - accel/amdxdna: Clear mailbox interrupt register during channel creation", " - accel/amdxdna: Fix deadlock between context destroy and job timeout", " - PCI: keystone: Exit ks_pcie_probe() for invalid mode", " - arm64: dts: rockchip: Move the EEPROM to correct I2C bus on Radxa ROCK", " 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 5A", " - arm64: dts: rockchip: Add eeprom vcc-supply for Radxa ROCK 3C", " - crypto: iaa - Fix incorrect return value in save_iaa_wq()", " - arm64: dts: qcom: qrb2210-rb1: Fix UART3 wakeup IRQ storm", " - drm/msm/dpu: drop dpu_hw_dsc_destroy() prototype", " - ps3disk: use memcpy_{from,to}_bvec index", " - PCI: Prevent resource tree corruption when BAR resize fails", " - bpf: Prevent nesting overflow in bpf_try_get_buffers", " - bpf: Handle return value of ftrace_set_filter_ip in register_fentry", " - selftests/bpf: Fix failure paths in send_signal test", " - mshv: Fix deposit memory in MSHV_ROOT_HVCALL", " - watchdog: wdat_wdt: Fix ACPI table leak in probe function", " - watchdog: starfive: Fix resource leak in probe error path", " - fuse_ctl_add_conn(): fix nlink breakage in case of early failure", " - tracefs: fix a leak in eventfs_create_events_dir()", " - NFSD/blocklayout: Fix minlength check in proc_layoutget", " - arm64: dts: imx95-tqma9596sa: fix TPM5 pinctrl node name", " - arm64: dts: imx95-tqma9596sa: reduce maximum FlexSPI frequency to 66MHz", " - block/blk-throttle: Fix throttle slice time for SSDs", " - drm/msm: Fix NULL pointer dereference in crashstate_get_vm_logs()", " - drm/msm: fix missing NULL check after kcalloc in crashstate_get_bos()", " - drm/msm/a2xx: stop over-complaining about the legacy firmware", " - net: phy: Add helper for fixing RGMII PHY mode based on internal mac", " delay", " - net: stmmac: dwmac-sophgo: Add phy interface filter", " - powerpc/64s/hash: Restrict stress_hpt_struct memblock region to within", " RMA limit", " - powerpc/64s/ptdump: Fix kernel_hash_pagetable dump for ISA v3.00 HPTE", " format", " - net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()", " - fs/ntfs3: out1 also needs to put mi", " - fs/ntfs3: Prevent memory leaks in add sub record", " - drm/mediatek: Fix CCORR mtk_ctm_s31_32_to_s1_n function issue", " - drm/msm/a6xx: Flush LRZ cache before PT switch", " - drm/msm/a6xx: Fix the gemnoc workaround", " - drm/msm/a6xx: Improve MX rail fallback in RPMH vote init", " - spi: sophgo: Fix incorrect use of bus width value macros", " - ipv6: clear RA flags when adding a static route", " - perf arm_spe: Fix memset subclass in operation", " - pwm: bcm2835: Make sure the channel is enabled after pwm_request()", " - scsi: ufs: rockchip: Reset controller on PRE_CHANGE of hce enable notify", " - net: phy: realtek: create rtl8211f_config_rgmii_delay()", " - iommu/vt-d: Fix unused invalidation hint in qi_desc_iotlb", " - wifi: mac80211: fix CMAC functions not handling errors", " - mfd: mt6397-irq: Fix missing irq_domain_remove() in error path", " - mfd: mt6358-irq: Fix missing irq_domain_remove() in error path", " - of/fdt: Consolidate duplicate code into helper functions", " - of/fdt: Fix incorrect use of dt_root_addr_cells in", " early_init_dt_check_kho()", " - leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM", " - phy: renesas: rcar-gen3-usb2: Fix an error handling path in", " rcar_gen3_phy_usb2_probe()", " - phy: rockchip: naneng-combphy: Add SoC prefix to register definitions", " - phy: rockchip: naneng-combphy: Fix PCIe L1ss support RK3562", " - phy: freescale: Initialize priv->lock", " - phy: rockchip: samsung-hdptx: Fix reported clock rate in high bpc mode", " - phy: rockchip: samsung-hdptx: Reduce ROPLL loop bandwidth", " - phy: rockchip: samsung-hdptx: Prevent Inter-Pair Skew from exceeding the", " limits", " - ASoC: SDCA: Fix missing dash in HIDE DisCo property", " - selftests/bpf: Use ASSERT_STRNEQ to factor in long slab cache names", " - net: phy: adin1100: Fix software power-down ready condition", " - cpuset: Treat cpusets in attaching as populated", " - clk: spacemit: Set clk_hw_onecell_data::num before using flex array", " - RAS: Report all ARM processor CPER information to userspace", " - usb: chaoskey: fix locking for O_NONBLOCK", " - usb: dwc2: fix hang during shutdown if set as peripheral", " - usb: dwc2: fix hang during suspend if set as peripheral", " - usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE", " - regulator: pca9450: Fix error code in probe()", " - selftests/bpf: skip test_perf_branches_hw() on unsupported platforms", " - selftests/bpf: Improve reliability of test_perf_branches_no_hw()", " - crypto: ccree - Correctly handle return of sg_nents_for_len", " - RISC-V: KVM: Fix guest page fault within HLV* instructions", " - erofs: correct FSDAX detection", " - RDMA/bnxt_re: Fix the inline size for GenP7 devices", " - RDMA/bnxt_re: Pass correct flag for dma mr creation", " - crypto: ahash - Fix crypto_ahash_import with partial block data", " - crypto: ahash - Zero positive err value in ahash_update_finish", " - ASoC: tas2781: correct the wrong period", " - wifi: mt76: mt7921: add MBSSID support", " - Revert \"wifi: mt76: mt792x: improve monitor interface handling\"", " - wifi: mt76: mt7996: fix max nss value when getting rx chainmask", " - wifi: mt76: mt7996: fix implicit beamforming support for mt7992", " - wifi: mt76: mt7996: fix several fields in mt7996_mcu_bss_basic_tlv()", " - wifi: mt76: mt7996: fix teardown command for an MLD peer", " - wifi: mt76: mt7996: set link_valid field when initializing wcid", " - wifi: mt76: mt7996: fix MLD group index assignment", " - wifi: mt76: mt7996: fix using wrong phy to start in mt7996_mac_restart()", " - wifi: mt76: mt7996: grab mt76 mutex in mt7996_mac_sta_event()", " - wifi: mt76: mt7996: skip deflink accounting for offchannel links", " - wifi: mt76: mt7996: Add missing locking in mt7996_mac_sta_rc_work()", " - firmware: stratix10-svc: fix make htmldocs warning for stratix10_svc", " - staging: fbtft: core: fix potential memory leak in fbtft_probe_common()", " - iommu/arm-smmu-v3: Fix error check in arm_smmu_alloc_cd_tables", " - btrfs: fix leaf leak in an error path in btrfs_del_items()", " - PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition", " - drm/nouveau: restrict the flush page to a 32-bit address", " - um: Don't rename vmap to kernel_vmap", " - iomap: always run error completions in user context", " - wifi: ieee80211: correct FILS status codes", " - backlight: lp855x: Fix lp855x.h kernel-doc warnings", " - iommu/arm-smmu-qcom: Enable use of all SMR groups when running bare-", " metal", " - RDMA/irdma: Fix data race in irdma_sc_ccq_arm", " - RDMA/irdma: Fix data race in irdma_free_pble", " - RDMA/irdma: Do not directly rely on IB_PD_UNSAFE_GLOBAL_RKEY", " - drm/panthor: Avoid adding of kernel BOs to extobj list", " - clocksource/drivers/ralink: Fix resource leaks in init error path", " - clocksource/drivers/stm: Fix double deregistration on probe failure", " - clocksource/drivers/nxp-stm: Fix section mismatches", " - clocksource/drivers/nxp-stm: Prevent driver unbind", " - ASoC: nau8325: use simple i2c probe function", " - ASoC: nau8325: add missing build config", " - [Config] enable NAU8325 codec", " - ASoC: fsl_xcvr: clear the channel status control memory", " - firmware_loader: make RUST_FW_LOADER_ABSTRACTIONS select FW_LOADER", " - [Config] enable RUST_FW_LOADER_ABSTRACTIONS", " - [Config] enable AMCC QT2025 PHY driver", " - greybus: gb-beagleplay: Fix timeout handling in bootloader functions", " - misc: rp1: Fix an error handling path in rp1_probe()", " - drm/amd/display: Fix logical vs bitwise bug in", " get_embedded_panel_info_v2_1()", " - hwmon: sy7636a: Fix regulator_enable resource leak on error path", " - ACPI: processor_core: fix map_x2apic_id for amd-pstate on am4", " - ublk: prevent invalid access with DEBUG", " - ext4: improve integrity checking in __mb_check_buddy by enhancing", " order-0 validation", " - selftests/net: packetdrill: pass send_omit_free to MSG_ZEROCOPY tests", " - of: Skip devicetree kunit tests when RISCV+ACPI doesn't populate root", " node", " - virtio_vdpa: fix misleading return in void function", " - virtio: fix typo in virtio_device_ready() comment", " - virtio: fix whitespace in virtio_config_ops", " - virtio: fix grammar in virtio_queue_info docs", " - virtio: fix virtqueue_set_affinity() docs", " - vdpa/mlx5: Fix incorrect error code reporting in query_virtqueues", " - vhost: Fix kthread worker cgroup failure handling", " - vdpa/pds: use %pe for ERR_PTR() in event handler registration", " - virtio: clean up features qword/dword terms", " - ASoC: Intel: catpt: Fix error path in hw_params()", " - spi: airoha-snfi: en7523: workaround flash damaging if UART_TXD was", " short to GND", " - ARM: dts: samsung: universal_c210: turn off SDIO WLAN chip during system", " suspend", " - ARM: dts: samsung: exynos4210-i9100: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4210-trats: turn off SDIO WLAN chip during", " system suspend", " - ARM: dts: samsung: exynos4412-midas: turn off SDIO WLAN chip during", " system suspend", " - Reinstate \"resource: avoid unnecessary lookups in find_next_iomem_res()\"", " - netfilter: flowtable: check for maximum number of encapsulations in", " bridge vlan", " - netfilter: nf_conncount: rework API to use sk_buff directly", " - netfilter: nft_connlimit: update the count if add was skipped", " - net: stmmac: fix rx limit check in stmmac_rx_zc()", " - mtd: rawnand: renesas: Handle devm_pm_runtime_enable() errors", " - vfio/pci: Use RCU for error/request triggers to avoid circular locking", " - net: phy: aquantia: check for NVMEM deferral", " - selftests: bonding: add delay before each xvlan_over_bond connectivity", " check", " - mtd: lpddr_cmds: fix signed shifts in lpddr_cmds", " - rqspinlock: Enclose lock/unlock within lock entry acquisitions", " - rqspinlock: Use trylock fallback when per-CPU rqnode is busy", " - remoteproc: qcom_q6v5_wcss: fix parsing of qcom,halt-regs", " - md/raid5: fix IO hang when array is broken with IO inflight", " - clk: keystone: fix compile testing", " - net: dsa: b53: fix VLAN_ID_IDX write size for BCM5325/65", " - net: dsa: b53: fix extracting VID from entry for BCM5325/65", " - net: dsa: b53: b53_arl_read{,25}(): use the entry for comparision", " - net: dsa: b53: move reading ARL entries into their own function", " - net: dsa: b53: move writing ARL entries into their own functions", " - net: dsa: b53: provide accessors for accessing ARL_SRCH_CTL", " - net: dsa: b53: split reading search entry into their own functions", " - net: dsa: b53: move ARL entry functions into ops struct", " - net: dsa: b53: add support for 5389/5397/5398 ARL entry format", " - net: dsa: b53: use same ARL search result offset for BCM5325/65", " - net: dsa: b53: fix CPU port unicast ARL entries for BCM5325/65", " - net: dsa: b53: add support for bcm63xx ARL entry format", " - net: dsa: b53: fix BCM5325/65 ARL entry multicast port masks", " - net: dsa: b53: fix BCM5325/65 ARL entry VIDs", " - net: hsr: create an API to get hsr port type", " - net: dsa: xrs700x: reject unsupported HSR configurations", " - perf jitdump: Add sym/str-tables to build-ID generation", " - perf tools: Mark split kallsyms DSOs as loaded", " - perf tools: Fix split kallsyms DSO counting", " - perf hist: In init, ensure mem_info is put on error paths", " - pinctrl: single: Fix incorrect type for error return variable", " - fbdev: ssd1307fb: fix potential page leak in ssd1307fb_probe()", " - 9p: fix cache/debug options printing in v9fs_show_options", " - sched/fair: Fix unfairness caused by stalled tg_load_avg_contrib when", " the last task migrates out", " - sched/core: Fix psi_dequeue() for Proxy Execution", " - f2fs: maintain one time GC mode is enabled during whole zoned GC cycle", " - kbuild: install-extmod-build: Fix when given dir outside the build dir", " - kbuild: install-extmod-build: Properly fix CC expansion when ccache is", " used", " - NFS: Avoid changing nlink when file removes and attribute updates race", " - fs/nls: Fix utf16 to utf8 conversion", " - NFS: Initialise verifiers for visible dentries in readdir and lookup", " - NFS: Initialise verifiers for visible dentries in nfs_atomic_open()", " - NFS: Initialise verifiers for visible dentries in", " _nfs4_open_and_get_state", " - panthor: save task pid and comm in panthor_group", " - Revert \"nfs: ignore SB_RDONLY when remounting nfs\"", " - Revert \"nfs: clear SB_RDONLY before getting superblock\"", " - Revert \"nfs: ignore SB_RDONLY when mounting nfs\"", " - NFS: Fix inheritance of the block sizes when automounting", " - fs/nls: Fix inconsistency between utf8_to_utf32() and utf32_to_utf8()", " - platform/x86: asus-wmi: use brightness_set_blocking() for kbd led", " - ASoC: bcm: bcm63xx-pcm-whistler: Check return value of", " of_dma_configure()", " - ASoC: amd: acp: Audio is not resuming after s0ix", " - ASoC: ak4458: Disable regulator when error happens", " - ASoC: ak5558: Disable regulator when error happens", " - f2fs: revert summary entry count from 2048 to 512 in 16kb block support", " - blk-mq: Abort suspend when wakeup events are pending", " - block: fix comment for op_is_zone_mgmt() to include RESET_ALL", " - nvme-auth: use kvfree() for memory allocated with kvcalloc()", " - drm/plane: Fix IS_ERR() vs NULL check in", " drm_plane_create_hotspot_properties()", " - regulator: fixed: Rely on the core freeing the enable GPIO", " - drm/nouveau: refactor deprecated strcpy", " - drm/nouveau: fix circular dep oops from vendored i2c encoder", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB1", " - cifs: Fix handling of a beyond-EOF DIO/unbuffered read over SMB2", " - docs: hwmon: fix link to g762 devicetree binding", " - i2c: spacemit: fix detect issue", " - dma/pool: eliminate alloc_pages warning in atomic_pool_expand", " - ALSA: uapi: Fix typo in asound.h comment", " - drm/amdkfd: Use huge page size to check split svm range alignment", " - rtc: gamecube: Check the return value of ioremap()", " - rtc: max31335: Fix ignored return value in set_alarm", " - ARM: 9464/1: fix input-only operand modification in", " load_unaligned_zeropad()", " - drm/xe/fbdev: use the same 64-byte stride alignment as i915", " - drm/i915/fbdev: make intel_framebuffer_create() error return handling", " explicit", " - drm/{i915, xe}/fbdev: pass struct drm_device to intel_fbdev_fb_alloc()", " - drm/{i915, xe}/fbdev: deduplicate struct drm_mode_fb_cmd2 init", " - drm/i915/fbdev: Hold runtime PM ref during fbdev BO creation", " - ASoC: amd: acp: update tdm channels for specific DAI", " - dm-raid: fix possible NULL dereference with undefined raid type", " - dm log-writes: Add missing set_freezable() for freezable kthread", " - efi/cper: Add a new helper function to print bitmasks", " - efi/cper: Adjust infopfx size to accept an extra space", " - efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs", " - perf/core: Fix missing read event generation on task exit", " - cpu: Make atomic hotplug callbacks run with interrupts disabled on UP", " - ocfs2: fix memory leak in ocfs2_merge_rec_left()", " - perf/x86/intel: Fix NULL event dereference crash in handle_pmi_common()", " - usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt", " - usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()", " - usb: phy: Initialize struct usb_phy list_head", " - usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when", " required", " - ALSA: hda/realtek: Add match for ASUS Xbox Ally projects", " - ALSA: hda/tas2781: fix speaker id retrieval for multiple probes", " - ASoC: codecs: nau8325: Silence uninitialized variables warnings", " - Linux 6.17.13", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68344", " - ALSA: wavefront: Fix integer overflow in sample size validation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68345", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_hda_read_acpi()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68346", " - ALSA: dice: fix buffer overflow in detect_stream_formats()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68323", " - usb: typec: ucsi: fix use-after-free caused by uec->work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68766", " - irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68324", " - scsi: imm: Fix use-after-free bug caused by unfinished delayed work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68756", " - block: Use RCU in blk_mq_[un]quiesce_tagset() instead of", " set->tag_list_lock", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68753", " - ALSA: firewire-motu: add bounds check in put_user loop for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68347", " - ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68348", " - block: fix memory leak in __blkdev_issue_zero_pages", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68764", " - NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68735", " - drm/panthor: Prevent potential UAF in group creation", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68349", " - NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in", " pnfs_mark_layout_stateid_invalid", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68754", " - rtc: amlogic-a4: fix double free caused by devm", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68325", " - net/sched: sch_cake: Fix incorrect qlen reduction in cake_drop", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68762", " - net: netpoll: initialize work queue before error checks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68352", " - spi: ch341: fix out-of-bounds memory access in ch341_transfer_one", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68752", " - iavf: Implement settime64 with -EOPNOTSUPP", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68354", " - regulator: core: Protect regulator_supply_alias_list with", " regulator_list_mutex", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68356", " - gfs2: Prevent recursive memory reclaim", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68758", " - backlight: led-bl: Add devlink to supplier LEDs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68358", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68359", " - btrfs: fix double free of qgroup record after failure to add delayed ref", " head", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68765", " - mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68360", " - wifi: mt76: wed: use proper wed reference in mt76 wed driver callabacks", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68738", " - wifi: mt76: mt7996: fix null pointer deref in mt7996_conf_tx()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68361", " - erofs: limit the level of fs stacking for file-backed mounts", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68739", " - PM / devfreq: hisi: Fix potential UAF in OPP handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68763", " - crypto: starfive - Correctly handle return of sg_nents_for_len", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68740", " - ima: Handle error code returned by ima_filter_rule_match()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68362", " - wifi: rtl818x: rtl8187: Fix potential buffer underflow in", " rtl8187_rx_cb()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68741", " - scsi: qla2xxx: Fix improper freeing of purex item", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68742", " - bpf: Fix invalid prog->stats access when update_effective_progs fails", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68759", " - wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68743", " - mshv: Fix create memory region overlap check", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68363", " - bpf: Check skb->transport_header is set in bpf_skb_check_mtu", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68751", " - s390/fpu: Fix false-positive kmsan report in fpu_vstl()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68744", " - bpf: Free special fields when update [lru_,]percpu_hash maps", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68364", " - ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68366", " - nbd: defer config unlock in nbd_genl_connect", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68367", " - macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68369", " - ntfs3: init run lock for extend inode", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68370", " - coresight: tmc: add the handle of the event to the path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68755", " - staging: most: remove broken i2c driver", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68371", " - scsi: smartpqi: Fix device resources accessed after device removal", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68372", " - nbd: defer config put in recv_work", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68373", " - md: avoid repeated calls to del_gendisk", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68374", " - md: fix rcu protection in md_wakeup_thread", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68375", " - perf/x86: Fix NULL event access and potential PEBS record loss", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68376", " - coresight: ETR: Fix ETR buffer use-after-free issue", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68746", " - spi: tegra210-quad: Fix timeout handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68760", " - iommu/amd: Fix potential out-of-bounds read in iommu_mmio_show", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68747", " - drm/panthor: Fix UAF on kernel BO VA nodes", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68748", " - drm/panthor: Fix UAF race between device unplug and FW event processing", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68749", " - accel/ivpu: Fix race condition when unbinding BOs", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68378", " - bpf: Fix stackmap overflow check in __bpf_get_stackid()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68379", " - RDMA/rxe: Fix null deref on srq->rq.queue after resize failure", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68380", " - wifi: ath11k: fix peer HE MCS assignment", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68724", " - crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68726", " - crypto: aead - Fix reqsize handling", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68727", " - ntfs3: Fix uninit buffer allocated by __getname()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68728", " - ntfs3: fix uninit memory after failed mi_read in mi_format_new", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68729", " - wifi: ath12k: Fix MSDU buffer types handling in RX error path", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68757", " - drm/vgem-fence: Fix potential deadlock on release", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68730", " - accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68732", " - gpu: host1x: Fix race in syncpt alloc/free", " * Questing update: v6.17.13 upstream stable release (LP: #2139960) //", " CVE-2025-68733", " - smack: fix bug: unprivileged task can create labels", " * Questing update: v6.17.12 upstream stable release (LP: #2139373)", " - Documentation: process: Also mention Sasha Levin as stable tree", " maintainer", " - jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system", " corrupted", " - ext4: refresh inline data size before write operations", " - ksmbd: ipc: fix use-after-free in ipc_msg_send_request", " - locking/spinlock/debug: Fix data-race in do_raw_write_lock", " - crypto: zstd - fix double-free in per-CPU stream cleanup", " - ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()", " - comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()", " - KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced", " - USB: serial: option: add Foxconn T99W760", " - USB: serial: option: add Telit Cinterion FE910C04 new compositions", " - USB: serial: option: move Telit 0x10c7 composition in the right place", " - USB: serial: ftdi_sio: match on interface number for jtag", " - serial: add support of CPCI cards", " - dt-bindings: serial: rsci: Drop \"uart-has-rtscts: false\"", " - serial: sh-sci: Fix deadlock during RSCI FIFO overrun error", " - USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC", " - USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC", " - ftrace: bpf: Fix IPMODIFY + DIRECT in modify_ftrace_direct()", " - spi: xilinx: increase number of retries before declaring stall", " - spi: imx: keep dma request disabled before dma transfer setup", " - ACPI: MRRM: Fix memory leaks and improve error handling", " - drm/vmwgfx: Use kref in vmw_bo_dirty", " - arm64: Reject modules with internal alternative callbacks", " - ALSA: hda/tas2781: Add new quirk for HP new projects", " - Bluetooth: btrtl: Avoid loading the config file on security chips", " - ASoC: SDCA: bug fix while parsing mipi-sdca-control-cn-list", " - smb: fix invalid username check in smb3_fs_context_parse_param()", " - drm/amdkfd: Fix GPU mappings for APU after prefetch", " - ALSA: usb-audio: Add native DSD quirks for PureAudio DAC series", " - HID: lenovo: fixup Lenovo Yoga Slim 7x Keyboard rdesc", " - bfs: Reconstruct file type when loading from disk", " - HID: hid-input: Extend Elan ignore battery quirk to USB", " - platform/x86/amd/pmc: Add support for Van Gogh SoC", " - platform/x86: hp-wmi: mark Victus 16-r0 and 16-s0 for victus_s fan and", " thermal profile support", " - nvme: fix admin request_queue lifetime", " - pinctrl: qcom: msm: Fix deadlock in pinmux configuration", " - platform/x86: acer-wmi: Ignore backlight event", " - HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list", " - platform/x86: huawei-wmi: add keys for HONOR models", " - platform/x86: intel-uncore-freq: Add additional client processors", " - platform/x86/amd: pmc: Add Lenovo Legion Go 2 to pmc quirk list", " - platform/x86/amd/pmc: Add spurious_8042 to Xbox Ally", " - sched_ext: Fix possible deadlock in the deferred_irq_workfn()", " - platform/x86/intel/hid: Add Nova Lake support", " - HID: elecom: Add support for ELECOM M-XT3URBK (018F)", " - sched_ext: Use IRQ_WORK_INIT_HARD() to initialize", " rq->scx.kick_cpus_irq_work", " - LoongArch: Mask all interrupts during kexec/kdump", " - samples: work around glibc redefining some of our defines wrong", " - platform/x86: hp-wmi: Add Omen 16-wf1xxx fan support", " - platform/x86: hp-wmi: Add Omen MAX 16-ah0xx fan support and thermal", " profile", " - wifi: rtl8xxxu: Add USB ID 2001:3328 for D-Link AN3U rev. A1", " - wifi: rtw88: Add USB ID 2001:3329 for D-Link AC13U rev. A1", " - iio: adc: ad4080: fix chip identification", " - comedi: c6xdigio: Fix invalid PNP driver unregistration", " - comedi: multiq3: sanitize config options in multiq3_attach()", " - comedi: check device's attached status in compat ioctls", " - staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser", " - staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing", " - staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing", " - Linux 6.17.12", " * Questing update: v6.17.11 upstream stable release (LP: #2138824)", " - Bluetooth: hci_core: Fix triggering cmd_timer for HCI_OP_NOP", " - Bluetooth: SMP: Fix not generating mackey and ltk when repairing", " - drm/bridge: sii902x: Fix HDMI detection with", " DRM_BRIDGE_ATTACH_NO_CONNECTOR", " - net: phy: mxl-gpy: fix bogus error on USXGMII and integrated PHY", " - net: aquantia: Add missing descriptor cache invalidation on ATL2", " - net: phy: mxl-gpy: fix link properties on USXGMII and internal PHYs", " - net: lan966x: Fix the initialization of taprio", " - drm/xe: Fix conversion from clock ticks to milliseconds", " - net/mlx5e: Fix validation logic in rate limiting", " - xsk: avoid overwriting skb fields for multi-buffer traffic", " - drm/amdgpu: fix cyan_skillfish2 gpu info fw handling", " - dma-direct: Fix missing sg_dma_len assignment in P2PDMA bus mappings", " - net: wwan: mhi: Keep modem name match with Foxconn T99W640", " - net: dsa: sja1105: fix SGMII linking at 10M or 100M but not passing", " traffic", " - eth: fbnic: Fix counter roll-over issue", " - net: mctp: unconditionally set skb->dev on dst output", " - net: fec: cancel perout_timer when PEROUT is disabled", " - net: fec: do not update PEROUT if it is enabled", " - net: fec: do not allow enabling PPS and PEROUT simultaneously", " - net: fec: do not register PPS event for PEROUT", " - iio: st_lsm6dsx: Fixed calibrated timestamp calculation", " - usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors", " - mailbox: mailbox-test: Fix debugfs_create_dir error checking", " - mailbox: mtk-cmdq: Refine DMA address handling for the command buffer", " - mailbox: pcc: don't zero error register", " - spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend()", " call", " - spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance", " - ovl: fail ovl_lock_rename_workdir() if either target is unhashed", " - riscv: dts: allwinner: d1: fix vlenb property", " - spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA", " - spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors", " - spi: spi-nxp-fspi: Add OCT-DTR mode support", " - spi: nxp-fspi: Propagate fwnode in ACPI case as well", " - spi: bcm63xx: fix premature CS deassertion on RX-only transactions", " - afs: Fix uninit var in afs_alloc_anon_key()", " - timekeeping: Fix error code in tk_aux_sysfs_init()", " - Revert \"perf/x86: Always store regs->ip in perf_callchain_kernel()\"", " - iio: buffer-dma: support getting the DMA channel", " - iio: buffer-dmaengine: enable .get_dma_dev()", " - iio: buffer: support getting dma channel from the buffer", " - iio: humditiy: hdc3020: fix units for temperature and humidity", " measurement", " - iio: humditiy: hdc3020: fix units for thresholds and hysteresis", " - iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields", " - iio: pressure: bmp280: correct meas_time_us calculation", " - iio:common:ssp_sensors: Fix an error handling path ssp_probe()", " - iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling", " - iio: accel: fix ADXL355 startup race condition", " - iio: adc: ad4030: Fix _scale value for common-mode channels", " - iio: adc: ad7124: fix temperature channel", " - iio: adc: ad7280a: fix ad7280_store_balance_timer()", " - iio: adc: ad7380: fix SPI offload trigger rate", " - iio: adc: rtq6056: Correct the sign bit index", " - MIPS: mm: Prevent a TLB shutdown on initial uniquification", " - MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow", " - virtio-net: avoid unnecessary checksum calculation on guest RX", " - vhost: rewind next_avail_head while discarding descriptors", " - ALSA: hda/cirrus fix cs420x MacPro 6,1 inverted jack detection", " - ALSA: usb-audio: Add DSD quirk for LEAK Stereo 230", " - arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos", " - arm64: dts: imx8dxl: Correct pcie-ep interrupt number", " - arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity", " - ARM: dts: nxp: imx6ul: correct SAI3 interrupt line", " - can: rcar_canfd: Fix CAN-FD mode as default", " - can: sja1000: fix max irq loop handling", " - can: sun4i_can: sun4i_can_interrupt(): fix max irq loop handling", " - counter: microchip-tcb-capture: Allow shared IRQ for multi-channel TCBs", " - dm-verity: fix unreliable memory allocation", " - drivers/usb/dwc3: fix PCI parent check", " - thunderbolt: Add support for Intel Wildcat Lake", " - slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves", " - nvmem: layouts: fix nvmem_layout_bus_uevent", " - pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag", " - r8169: fix RTL8127 hang on suspend/shutdown", " - regulator: rtq2208: Correct buck group2 phase mapping logic", " - regulator: rtq2208: Correct LDO2 logic judgment bits", " - iommufd/driver: Fix counter initialization for counted_by annotation", " - mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level", " - mptcp: clear scheduled subflows on retransmit", " - mptcp: Initialise rcv_mss before calling tcp_send_active_reset() in", " mptcp_do_fastclose().", " - serial: 8250: Fix 8250_rsa symbol loop", " - serial: amba-pl011: prefer dma_mapping_error() over explicit address", " checking", " - usb: cdns3: Fix double resource release in cdns3_pci_probe", " - USB: storage: Remove subclass and protocol overrides from Novatek quirk", " - usb: typec: ucsi: psy: Set max current to zero when disconnected", " - usb: dwc3: pci: add support for the Intel Nova Lake -S", " - usb: dwc3: pci: Sort out the Intel device IDs", " - xhci: fix stale flag preventig URBs after link state error is cleared", " - xhci: dbgtty: Fix data corruption when transmitting data form DbC to", " host", " - xhci: dbgtty: fix device unregister", " - USB: serial: ftdi_sio: add support for u-blox EVK-M101", " - USB: serial: option: add support for Rolling RW101R-GL", " - drm: sti: fix device leaks at component probe", " - drm/i915/psr: Reject async flips when selective fetch is enabled", " - drm/amdgpu: attach tlb fence to the PTs update", " - drm/amd/amdgpu: reserve vm invalidation engine for uni_mes", " - drm/amd/display: Don't change brightness for disabled connectors", " - drm/amd/display: Increase EDID read retries", " - net: dsa: microchip: common: Fix checks on irq_find_mapping()", " - net: dsa: microchip: ptp: Fix checks on irq_find_mapping()", " - net: dsa: microchip: Free previously initialized ports on init failures", " - net: dsa: microchip: Fix symetry in ksz_ptp_msg_irq_{setup/free}()", " - mm: swap: remove duplicate nr_swap_pages decrement in", " get_swap_page_of_type()", " - usb: udc: Add trace event for usb_gadget_set_state", " - Revert \"ACPI: Suppress misleading SPCR console message when SPCR table", " is absent\"", " - spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm", " - Linux 6.17.11", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68282", " - usb: gadget: udc: fix use-after-free in usb_gadget_state_work", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68283", " - libceph: replace BUG_ON with bounds check for map->max_osd", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68284", " - libceph: prevent potential out-of-bounds writes in", " handle_auth_session_key()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68285", " - libceph: fix potential use-after-free in have_mon_and_osd_map()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68338", " - net: dsa: microchip: Don't free uninitialized ksz_irq", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68286", " - drm/amd/display: Check NULL before accessing", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68326", " - drm/xe/guc: Fix stack_depot usage", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68287", " - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests()", " call paths", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68331", " - usb: uas: fix urb unmapping issue when the uas device is remove during", " ongoing data transfer", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40345", " - usb: storage: sddr55: Reject out-of-bound new_pba", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68288", " - usb: storage: Fix memory leak in USB bulk transport", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68327", " - usb: renesas_usbhs: Fix synchronous external abort on unbind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68289", " - usb: gadget: f_eem: Fix memory leak in eem_unwrap", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68290", " - most: usb: fix double free on late probe failure", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68292", " - mm/memfd: fix information leak in hugetlb folios", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68293", " - mm/huge_memory: fix NULL pointer deference when splitting folio", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68328", " - firmware: stratix10-svc: fix bug in saving controller data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68294", " - io_uring/net: ensure vectored buffer node import is tied to notification", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68295", " - smb: client: fix memory leak in cifs_construct_tcon()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68296", " - drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68297", " - ceph: fix crash in process_v2_sparse_read() for encrypted directories", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68298", " - Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68339", " - atm/fore200e: Fix possible data race in fore200e_open()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68329", " - tracing: Fix WARN_ON in tracing_buffers_mmap_close for split VMAs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68330", " - iio: accel: bmc150: Fix irq assumption regression", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68299", " - afs: Fix delayed allocation of a cell's anonymous key", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68300", " - fs/namespace: fix reference leak in grab_requested_mnt_ns", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68301", " - net: atlantic: fix fragment overflow handling in RX path", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-40290", " - xsk: avoid data corruption on cq descriptor number", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68302", " - net: sxgbe: fix potential NULL dereference in sxgbe_rx()", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68340", " - team: Move team device type change at the end of team_port_add", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68303", " - platform/x86: intel: punit_ipc: fix memory corruption", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68341", " - veth: reduce XDP no_direct return section to fix race", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68304", " - Bluetooth: hci_core: lookup hci_conn on RX path on protocol side", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68305", " - Bluetooth: hci_sock: Prevent race in socket write iter and sock bind", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68306", " - Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso", " interface", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68342", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing data", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68343", " - can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before", " accessing header", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68307", " - can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted", " URBs", " * Questing update: v6.17.11 upstream stable release (LP: #2138824) //", " CVE-2025-68308", " - can: kvaser_usb: leaf: Fix potential infinite loop in command parsers", " * Questing update: v6.17.10 upstream stable release (LP: #2137723)", " - arm64: dts: rockchip: Remove non-functioning CPU OPPs from RK3576", " - HID: amd_sfh: Stop sensor before starting", " - HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155", " - arm64: dts: rockchip: Fix vccio4-supply on rk3566-pinetab2", " - arm64: dts: rockchip: fix PCIe 3.3V regulator voltage on orangepi-5", " - reset: imx8mp-audiomix: Fix bad mask values", " - arm64: dts: rockchip: include rk3399-base instead of rk3399 in", " rk3399-op1", " - arm64: dts: rockchip: disable HS400 on RK3588 Tiger", " - KVM: SVM: Fix redundant updates of LBR MSR intercepts", " - xfs: check the return value of sb_min_blocksize() in xfs_fs_fill_super", " - isofs: check the return value of sb_min_blocksize() in isofs_fill_super", " - shmem: fix tmpfs reconfiguration (remount) when noswap is set", " - exfat: check return value of sb_min_blocksize in exfat_read_boot_sector", " - mptcp: Disallow MPTCP subflows from sockmap", " - s390/mm: Fix __ptep_rdp() inline assembly", " - ACPI: APEI: EINJ: Fix EINJV2 initialization and injection", " - ata: libata-scsi: Fix system suspend for a security locked drive", " - selinux: rename task_security_struct to cred_security_struct", " - selinux: move avdcache to per-task security struct", " - smb: client: introduce close_cached_dir_locked()", " - wifi: rtw89: hw_scan: Don't let the operating channel be last", " - ata: libata-scsi: Add missing scsi_device_put() in ata_scsi_dev_rescan()", " - net: dsa: microchip: lan937x: Fix RGMII delay tuning", " - Revert \"drm/tegra: dsi: Clear enable register if powered by bootloader\"", " - Input: goodix - add support for ACPI ID GDIX1003", " - nvme: nvme-fc: move tagset removal to nvme_fc_delete_ctrl()", " - PM: sleep: core: Fix runtime PM enabling in device_resume_early()", " - MIPS: Malta: Fix !EVA SOC-it PCI MMIO", " - dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groups", " - LoongArch: Don't panic if no valid cache info for PCI", " - LoongArch: Fix NUMA node parsing with numa_memblks", " - platform/x86: alienware-wmi-wmax: Fix \"Alienware m16 R1 AMD\" quirk order", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"M\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"X\" family", " - platform/x86: alienware-wmi-wmax: Add support for the whole \"G\" family", " - platform/x86: alienware-wmi-wmax: Add AWCC support to Alienware 16", " Aurora", " - mptcp: fix ack generation for fallback msk", " - mptcp: fix duplicate reset on fastclose", " - mptcp: fix premature close in case of fallback", " - selftests: mptcp: join: endpoints: longer timeout", " - selftests: mptcp: join: userspace: longer timeout", " - mptcp: avoid unneeded subflow-level drops", " - mptcp: decouple mptcp fastclose from tcp close", " - mptcp: do not fallback when OoO is present", " - drm/tegra: dc: Fix reference leak in tegra_dc_couple()", " - drm/amdgpu: Skip emit de meta data on gfx11 with rs64 enabled", " - drm/amd/display: Increase DPCD read retries", " - drm/amd/display: Move sleep into each retry for retrieve_link_cap()", " - drm/amd/display: Clear the CUR_ENABLE register on DCN20 on DPP5", " - mm/truncate: unmap large folio on split failure", " - pinctrl: mediatek: mt8196: align register base names to dt-bindings ones", " - pinctrl: mediatek: mt8189: align register base names to dt-bindings ones", " - xfrm: drop SA reference in xfrm_state_update if dir doesn't match", " - xfrm: call xfrm_dev_state_delete when xfrm_state_migrate fails to add", " the state", " - xfrm: set err and extack on failure to create pcpu SA", " - clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical", " - clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical", " - clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate", " - pinctrl: realtek: Select REGMAP_MMIO for RTD driver", " - xfrm: Check inner packet family directly from skb_dst", " - xfrm: Determine inner GSO type from packet inner protocol", " - xfrm: Prevent locally generated packets from direct output in tunnel", " mode", " - pinctrl: cirrus: Fix fwnode leak in cs42l43_pin_probe()", " - platform/x86: msi-wmi-platform: Only load on MSI devices", " - platform/x86: msi-wmi-platform: Fix typo in WMI GUID", " - mips: dts: econet: fix EN751221 core type", " - mlxsw: spectrum: Fix memory leak in mlxsw_sp_flower_stats()", " - net: dsa: hellcreek: fix missing error handling in LED registration", " - net: mlxsw: linecards: fix missing error check in", " mlxsw_linecard_devlink_info_get()", " - tools: riscv: Fixed misalignment of CSR related definitions", " - nvmet-auth: update sc_c in target host hash calculation", " - drm/i915/xe3lpd: Load DMC for Xe3_LPD version 30.02", " - selftests: net: lib: Do not overwrite error messages", " - net: airoha: Add wlan flowtable TX offload", " - net: airoha: Do not loopback traffic to GDM2 if it is available on the", " device", " - platform/x86/intel/speed_select_if: Convert PCIBIOS_* return codes to", " errnos", " - platform/x86: intel-uncore-freq: fix all header kernel-doc warnings", " - drm/pcids: Split PTL pciids group to make wcl subplatform", " - drm/i915/display: Add definition for wcl as subplatform", " - drm/i915/xe3: Restrict PTL intel_encoder_is_c10phy() to only PHY A", " - drm/xe/kunit: Fix forcewake assertion in mocs test", " - drm/xe/irq: Handle msix vector0 interrupt", " - pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()", " - af_unix: Read sk_peek_offset() again after sleeping in", " unix_stream_read_generic().", " - net: phylink: add missing supported link modes for the fixed-link", " - tick/sched: Fix bogus condition in report_idle_softirq()", " - LoongArch: Use UAPI types in ptrace UAPI header", " - perf: Fix 0 count issue of cpu-clock", " - timekeeping: Fix resource leak in tk_aux_sysfs_init() error paths", " - MIPS: kernel: Fix random segmentation faults", " - ALSA: hda/realtek: Add quirk for Lenovo Yoga 7 2-in-1 14AKP10", " - sched_ext: Allocate scx_kick_cpus_pnt_seqs lazily using kvzalloc()", " - bcma: don't register devices disabled in OF", " - sched_ext: defer queue_balance_callback() until after ops.dispatch", " - ASoC: rt721: fix prepare clock stop failed", " - cifs: fix typo in enable_gcm_256 module parameter", " - scsi: core: Fix a regression triggered by scsi_host_busy()", " - ALSA: hda/realtek: Fix mute led for HP Victus 15-fa1xxx (MB 8C2D)", " - perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lake", " - x86/microcode/AMD: Limit Entrysign signature checking to known", " generations", " - selftests: cachestat: Fix warning on declaration under label", " - smb: client: handle lack of IPC in dfs_cache_refresh()", " - net: tls: Change async resync helpers argument", " - blk-crypto: use BLK_STS_INVAL for alignment errors", " - net: tls: Cancel RX async resync request on rcd_delta overflow", " - x86/CPU/AMD: Extend Zen6 model range", " - kconfig/mconf: Initialize the default locale at startup", " - kconfig/nconf: Initialize the default locale at startup", " - drm/xe: Prevent BIT() overflow when handling invalid prefetch region", " - ALSA: usb-audio: fix uac2 clock source at terminal parser", " - tracing/tools: Fix incorrcet short option in usage text for --threads", " - btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name", " - smb: client: fix incomplete backport in cfids_invalidation_worker()", " - drm/amdgpu/jpeg: Move parse_cs to amdgpu_jpeg.c", " - drm/amdgpu/jpeg: Add parse_cs for JPEG5_0_1", " - xfs: Replace strncpy with memcpy", " - drm/amd/display: Insert dccg log for easy debug", " - drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched", " - tty/vt: fix up incorrect backport to stable releases", " - Revert \"drm/i915/dp: Reject HBR3 when sink doesn't support TPS4\"", " - drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2", " - sched_ext: Fix scx_kick_pseqs corruption on concurrent scheduler loads", " - sched_ext: fix flag check for deferred callbacks", " - Linux 6.17.10", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68221", " - mptcp: fix address removal logic in mptcp_pm_nl_rm_addr", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40246", " - xfs: fix out of bounds memory read error in symlink repair", " * Intel,External monitor flickers or no output when connected to WD25 dock", " (LP: #2136979) // Questing update: v6.17.10 upstream stable release", " (LP: #2137723)", " - drm/i915/psr: Check drm_dp_dpcd_read return value on PSR dpcd init", " - drm/i915/dp_mst: Disable Panel Replay", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68230", " - drm/amdgpu: fix gpu page fault after hibernation on PF passthrough", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68220", " - net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return", " NULL on error", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68236", " - scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40247", " - drm/msm: Fix pgtable prealloc error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40248", " - vsock: Ignore signal/timeout on connect() if already established", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68219", " - cifs: fix memory leak in smb3_fs_context_parse_param error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40249", " - gpio: cdev: make sure the cdev fd is still active before emitting events", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40250", " - net/mlx5: Clean up only new IRQ glue on request_irq() failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40251", " - devlink: rate: Unset parent pointer in devl_rate_nodes_destroy", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68222", " - pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68215", " - ice: fix PTP cleanup on driver removal in error path", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68213", " - idpf: fix possible vport_config NULL pointer deref in remove", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40252", " - net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont()", " and qede_tpa_end()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40253", " - s390/ctcm: Fix double-kfree", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68218", " - nvme-multipath: fix lockdep WARN due to partition scan work", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68232", " - veth: more robust handing of race to avoid txq getting stuck", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40254", " - net: openvswitch: remove never-working support for setting nsh fields", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68233", " - drm/tegra: Add call to put_pid()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40255", " - net: core: prevent NULL deref in generic_hwtstamp_ioctl_lower()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68228", " - drm/plane: Fix create_in_format_blob() return value", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68223", " - drm/radeon: delete radeon_fence_process in is_signaled, no deadlock", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40257", " - mptcp: fix a race in mptcp_pm_del_add_timer()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40258", " - mptcp: fix race condition in mptcp_schedule_work()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68216", " - LoongArch: BPF: Disable trampoline for kernel module function trace", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68229", " - scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40259", " - scsi: sg: Do not sleep in atomic context", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40260", " - sched_ext: Fix scx_enable() crash on helper kthread creation failure", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40261", " - nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68235", " - nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68231", " - mm/mempool: fix poisoning order>0 pages with HIGHMEM", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68217", " - Input: pegasus-notetaker - fix potential out-of-bounds access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40262", " - Input: imx_sc_key - fix memory corruption on unload", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40263", " - Input: cros_ec_keyb - fix an invalid memory access", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68234", " - io_uring/cmd_net: fix wrong argument types for skb_queue_splice()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40264", " - be2net: pass wrb_params in case of OS2BMC", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68225", " - lib/test_kho: check if KHO is enabled", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68227", " - mptcp: Fix proto fallback detection with BPF", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68237", " - mtdchar: fix integer overflow in read/write ioctls", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68212", " - fs: Fix uninitialized 'offp' in statmount_string()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68238", " - mtd: rawnand: cadence: fix DMA device NULL pointer dereference", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40265", " - vfat: fix missing sb_min_blocksize() return value checks", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-68214", " - timers: Fix NULL function pointer race in timer_shutdown_sync()", " * Questing update: v6.17.10 upstream stable release (LP: #2137723) //", " CVE-2025-40266", " - KVM: arm64: Check the untrusted offset in FF-A memory share", "" ], "package": "linux-riscv-6.17", "version": "6.17.0-16.16.1~24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2141143, 1786013, 2141144, 1786013, 2141148, 1786013, 2116169, 2127764, 2031531, 2137613, 2131066, 2129580, 2130998, 2138423, 2124276, 2138192, 2134491, 2137615, 2067642, 2127044, 2122398, 2133144, 2121200, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139960, 2139373, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2138824, 2137723, 2137723, 2137723, 2136979, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723, 2137723 ], "author": "Sarah Emery ", "date": "Thu, 19 Feb 2026 21:51:40 +0100" } ], "notes": "linux-tools-6.17.0-19-generic version '6.17.0-19.19.1~24.04.1' (source package linux-riscv-6.17 version '6.17.0-19.19.1~24.04.1') was added. linux-tools-6.17.0-19-generic version '6.17.0-19.19.1~24.04.1' has the same source package name, linux-riscv-6.17, as removed package linux-headers-6.17.0-14-generic. As such we can use the source package version of the removed package, '6.17.0-14.14.1~24.04.1', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-6.17.0-14-generic", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-6.17.0-14-generic", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "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.17.0-14-generic", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "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-riscv-6.17-headers-6.17.0-14", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "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-riscv-6.17-tools-6.17.0-14", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "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-tools-6.17.0-14-generic", "from_version": { "source_package_name": "linux-riscv-6.17", "source_package_version": "6.17.0-14.14.1~24.04.1", "version": "6.17.0-14.14.1~24.04.1" }, "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 20260225 to 20260321", "from_series": "noble", "to_series": "noble", "from_serial": "20260225", "to_serial": "20260321", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }