{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-image-6.8.0-117-generic", "linux-modules-6.8.0-117-generic" ], "removed": [ "linux-image-6.8.0-110-generic", "linux-modules-6.8.0-110-generic" ], "diff": [ "curl", "distro-info-data", "dpkg", "kmod", "libcurl4t64", "libgnutls30t64", "libkmod2", "libnghttp2-14", "libpng16-16t64", "linux-image-virtual", "openssh-client", "openssh-server", "openssh-sftp-server", "sed", "xxd" ] } }, "diff": { "deb": [ { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.8", "version": "8.5.0-2ubuntu10.8" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.9", "version": "8.5.0-2ubuntu10.9" }, "cves": [ { "cve": "CVE-2026-4873", "url": "https://ubuntu.com/security/CVE-2026-4873", "cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-5545", "url": "https://ubuntu.com/security/CVE-2026-5545", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. 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 criteria must 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. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-5773", "url": "https://ubuntu.com/security/CVE-2026-5773", "cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. 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 criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6253", "url": "https://ubuntu.com/security/CVE-2026-6253", "cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6276", "url": "https://ubuntu.com/security/CVE-2026-6276", "cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-7168", "url": "https://ubuntu.com/security/CVE-2026-7168", "cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4873", "url": "https://ubuntu.com/security/CVE-2026-4873", "cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-5545", "url": "https://ubuntu.com/security/CVE-2026-5545", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. 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 criteria must 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. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-5773", "url": "https://ubuntu.com/security/CVE-2026-5773", "cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. 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 criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6253", "url": "https://ubuntu.com/security/CVE-2026-6253", "cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6276", "url": "https://ubuntu.com/security/CVE-2026-6276", "cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-7168", "url": "https://ubuntu.com/security/CVE-2026-7168", "cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: connection reuse ignores TLS requirement", " - debian/patches/CVE-2026-4873.patch: do not reuse a non-tls starttls", " connection if new requires TLS in lib/url.c.", " - CVE-2026-4873", " * SECURITY UPDATE: wrong reuse of HTTP Negotiate connection", " - debian/patches/CVE-2026-5545.patch: improve connection reuse on", " negotiate in lib/url.c.", " - CVE-2026-5545", " * SECURITY UPDATE: wrong reuse of SMB connection", " - debian/patches/CVE-2026-5773.patch: disable connection reuse for", " SMB(S) in lib/smb.c.", " - CVE-2026-5773", " * SECURITY UPDATE: proxy credentials leak over redirect-to proxy", " - debian/patches/CVE-2026-6253.patch: clear the proxy credentials as", " well on port or scheme change in lib/transfer.*, tests/*.", " - CVE-2026-6253", " * SECURITY UPDATE: stale custom cookie host causes cookie leak", " - debian/patches/CVE-2026-6276.patch: move cookiehost to struct", " SingleRequest in lib/http.c, lib/url.c, lib/urldata.h, tests/*.", " - CVE-2026-6276", " * SECURITY UPDATE: netrc credential leak with reused proxy connection", " - debian/patches/CVE-2026-6429-pre1.patch: prevent secure schemes", " pushed over insecure connections in lib/http2.c.", " - debian/patches/CVE-2026-6429-pre2.patch: same origin tests in", " lib/http2.c, lib/urlapi-int.h, lib/urlapi.c.", " - debian/patches/CVE-2026-6429.patch: clear credentials better on", " redirect in lib/transfer.c, tests/*.", " - CVE-2026-6429", " * SECURITY UPDATE: cross-proxy Digest auth state leak", " - debian/patches/CVE-2026-7168.patch: clear proxy auth properties when", " switching in lib/setopt.c, lib/vauth/vauth.h, tests/*.", " - CVE-2026-7168", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 29 Apr 2026 07:35:43 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "distro-info-data", "from_version": { "source_package_name": "distro-info-data", "source_package_version": "0.60ubuntu0.5", "version": "0.60ubuntu0.5" }, "to_version": { "source_package_name": "distro-info-data", "source_package_version": "0.60ubuntu0.6", "version": "0.60ubuntu0.6" }, "cves": [], "launchpad_bugs_fixed": [ 2150234 ], "changes": [ { "cves": [], "log": [ "", " * Add Ubuntu 26.10 \"Stonking Stingray\" (LP: #2150234)", "" ], "package": "distro-info-data", "version": "0.60ubuntu0.6", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2150234 ], "author": "Oliver Reiche ", "date": "Tue, 28 Apr 2026 16:16:45 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "dpkg", "from_version": { "source_package_name": "dpkg", "source_package_version": "1.22.6ubuntu6.5", "version": "1.22.6ubuntu6.5" }, "to_version": { "source_package_name": "dpkg", "source_package_version": "1.22.6ubuntu6.6", "version": "1.22.6ubuntu6.6" }, "cves": [ { "cve": "CVE-2026-2219", "url": "https://ubuntu.com/security/CVE-2026-2219", "cve_description": "It was discovered that dpkg-deb (a component of dpkg, the Debian package management system) does not properly validate the end of the data stream when uncompressing a zstd-compressed .deb archive, which may result in denial of service (infinite loop spinning the CPU).", "cve_priority": "medium", "cve_public_date": "2026-03-07 09:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-2219", "url": "https://ubuntu.com/security/CVE-2026-2219", "cve_description": "It was discovered that dpkg-deb (a component of dpkg, the Debian package management system) does not properly validate the end of the data stream when uncompressing a zstd-compressed .deb archive, which may result in denial of service (infinite loop spinning the CPU).", "cve_priority": "medium", "cve_public_date": "2026-03-07 09:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: infinite loop uncompressing a zstd-compressed .deb archive", " - lib/dpkg/compress.c: terminate zstd decompression when we have no", " more data.", " - 6610297a62c0780dd0e80b0e302ef64fdcc9d313", " - CVE-2026-2219", "" ], "package": "dpkg", "version": "1.22.6ubuntu6.6", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 06 May 2026 13:38:18 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "kmod", "from_version": { "source_package_name": "kmod", "source_package_version": "31+20240202-2ubuntu7.1", "version": "31+20240202-2ubuntu7.1" }, "to_version": { "source_package_name": "kmod", "source_package_version": "31+20240202-2ubuntu7.2", "version": "31+20240202-2ubuntu7.2" }, "cves": [ { "cve": "CVE-2026-31431", "url": "https://ubuntu.com/security/CVE-2026-31431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2150743 ], "changes": [ { "cves": [ { "cve": "CVE-2026-31431", "url": "https://ubuntu.com/security/CVE-2026-31431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" } ], "log": [ "", " * Disable loading of algif_aead module to mitigate CVE-2026-31431", " (LP: #2150743)", " - debian/modprobe.d/disable-algif_aead.conf", "" ], "package": "kmod", "version": "31+20240202-2ubuntu7.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2150743 ], "author": "Marc Deslauriers ", "date": "Thu, 30 Apr 2026 08:32:11 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl4t64", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.8", "version": "8.5.0-2ubuntu10.8" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.9", "version": "8.5.0-2ubuntu10.9" }, "cves": [ { "cve": "CVE-2026-4873", "url": "https://ubuntu.com/security/CVE-2026-4873", "cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-5545", "url": "https://ubuntu.com/security/CVE-2026-5545", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. 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 criteria must 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. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-5773", "url": "https://ubuntu.com/security/CVE-2026-5773", "cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. 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 criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6253", "url": "https://ubuntu.com/security/CVE-2026-6253", "cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6276", "url": "https://ubuntu.com/security/CVE-2026-6276", "cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-7168", "url": "https://ubuntu.com/security/CVE-2026-7168", "cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-4873", "url": "https://ubuntu.com/security/CVE-2026-4873", "cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-5545", "url": "https://ubuntu.com/security/CVE-2026-5545", "cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. 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 criteria must 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. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-5773", "url": "https://ubuntu.com/security/CVE-2026-5773", "cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. 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 criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6253", "url": "https://ubuntu.com/security/CVE-2026-6253", "cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6276", "url": "https://ubuntu.com/security/CVE-2026-6276", "cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.", "cve_priority": "low", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-6429", "url": "https://ubuntu.com/security/CVE-2026-6429", "cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" }, { "cve": "CVE-2026-7168", "url": "https://ubuntu.com/security/CVE-2026-7168", "cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.", "cve_priority": "medium", "cve_public_date": "2026-05-13 13:01:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: connection reuse ignores TLS requirement", " - debian/patches/CVE-2026-4873.patch: do not reuse a non-tls starttls", " connection if new requires TLS in lib/url.c.", " - CVE-2026-4873", " * SECURITY UPDATE: wrong reuse of HTTP Negotiate connection", " - debian/patches/CVE-2026-5545.patch: improve connection reuse on", " negotiate in lib/url.c.", " - CVE-2026-5545", " * SECURITY UPDATE: wrong reuse of SMB connection", " - debian/patches/CVE-2026-5773.patch: disable connection reuse for", " SMB(S) in lib/smb.c.", " - CVE-2026-5773", " * SECURITY UPDATE: proxy credentials leak over redirect-to proxy", " - debian/patches/CVE-2026-6253.patch: clear the proxy credentials as", " well on port or scheme change in lib/transfer.*, tests/*.", " - CVE-2026-6253", " * SECURITY UPDATE: stale custom cookie host causes cookie leak", " - debian/patches/CVE-2026-6276.patch: move cookiehost to struct", " SingleRequest in lib/http.c, lib/url.c, lib/urldata.h, tests/*.", " - CVE-2026-6276", " * SECURITY UPDATE: netrc credential leak with reused proxy connection", " - debian/patches/CVE-2026-6429-pre1.patch: prevent secure schemes", " pushed over insecure connections in lib/http2.c.", " - debian/patches/CVE-2026-6429-pre2.patch: same origin tests in", " lib/http2.c, lib/urlapi-int.h, lib/urlapi.c.", " - debian/patches/CVE-2026-6429.patch: clear credentials better on", " redirect in lib/transfer.c, tests/*.", " - CVE-2026-6429", " * SECURITY UPDATE: cross-proxy Digest auth state leak", " - debian/patches/CVE-2026-7168.patch: clear proxy auth properties when", " switching in lib/setopt.c, lib/vauth/vauth.h, tests/*.", " - CVE-2026-7168", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.9", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 29 Apr 2026 07:35:43 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libgnutls30t64", "from_version": { "source_package_name": "gnutls28", "source_package_version": "3.8.3-1.1ubuntu3.5", "version": "3.8.3-1.1ubuntu3.5" }, "to_version": { "source_package_name": "gnutls28", "source_package_version": "3.8.3-1.1ubuntu3.6", "version": "3.8.3-1.1ubuntu3.6" }, "cves": [ { "cve": "CVE-2026-33846", "url": "https://ubuntu.com/security/CVE-2026-33846", "cve_description": "A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-05-04 10:15:00 UTC" }, { "cve": "CVE-2026-42009", "url": "https://ubuntu.com/security/CVE-2026-42009", "cve_description": "A flaw was found in gnutls. A remote attacker could exploit an issue in the Datagram Transport Layer Security (DTLS) packet reordering logic. The comparator function, responsible for ordering DTLS packets by sequence numbers, did not correctly handle packets with duplicate sequence numbers. This could lead to unstable packet ordering or undefined behavior, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-05-18 13:16:00 UTC" }, { "cve": "CVE-2026-33845", "url": "https://ubuntu.com/security/CVE-2026-33845", "cve_description": "A flaw in GnuTLS DTLS handshake parsing allows malformed fragments with zero length and non-zero offset, leading to an integer underflow during reassembly and resulting in an out-of-bounds read. This issue is remotely exploitable and may cause information disclosure or denial of service.", "cve_priority": "medium", "cve_public_date": "2026-04-30 18:16:00 UTC" }, { "cve": "CVE-2026-3832", "url": "https://ubuntu.com/security/CVE-2026-3832", "cve_description": "A flaw was found in gnutls. A remote attacker could exploit this vulnerability by presenting a specially crafted Online Certificate Status Protocol (OCSP) response during a TLS handshake. Due to a logic error in how gnutls processes multi-record OCSP responses, a client with OCSP verification enabled may incorrectly accept a revoked server certificate, potentially leading to a compromise of trust.", "cve_priority": "medium", "cve_public_date": "2026-04-30 18:16:00 UTC" }, { "cve": "CVE-2026-3833", "url": "https://ubuntu.com/security/CVE-2026-3833", "cve_description": "A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of `nameConstraints` labels, specifically for `dNSName` (DNS) or `rfc822Name` (email) constraints within `excludedSubtrees` or `permittedSubtrees`. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.", "cve_priority": "medium", "cve_public_date": "2026-04-30 18:16:00 UTC" }, { "cve": "CVE-2026-42011", "url": "https://ubuntu.com/security/CVE-2026-42011", "cve_description": "A flaw was found in gnutls. This vulnerability occurs because permitted name constraints were incorrectly ignored when previous Certificate Authorities (CAs) only had excluded name constraints. A remote attacker could exploit this to bypass critical name constraint checks during certificate validation. This bypass could lead to the acceptance of invalid certificates, potentially enabling spoofing or man-in-the-middle attacks against affected systems.", "cve_priority": "medium", "cve_public_date": "2026-05-07 15:16:00 UTC" }, { "cve": "CVE-2026-42010", "url": "https://ubuntu.com/security/CVE-2026-42010", "cve_description": "A flaw was found in gnutls. Servers configured with RSA-PSK (Rivest–Shamir–Adleman – Pre-Shared Key) wrongfully matched usernames containing a NUL character with truncated usernames. A remote attacker could exploit this by sending a specially crafted username, leading to an authentication bypass. This vulnerability allows an attacker to gain unauthorized access by circumventing the authentication process.", "cve_priority": "medium", "cve_public_date": "2026-05-07 12:16:00 UTC" }, { "cve": "CVE-2026-5260", "url": "https://ubuntu.com/security/CVE-2026-5260", "cve_description": "For a server using an RSA key backed by a PKCS#11 token, a client sending an extremely short premaster secret during an RSA key exchange could trigger a short heap overread.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-42012", "url": "https://ubuntu.com/security/CVE-2026-42012", "cve_description": "Certificates containing URI or SRV Subject Alternative Names would fall back to checking DNS hostnames against Common Name, allowing potential misuse of such certificates beyond their original purpose.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-42013", "url": "https://ubuntu.com/security/CVE-2026-42013", "cve_description": "Validation of certificates with oversized Subject Alternative Names would fall back to checking DNS hostnames against Common Name.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-42014", "url": "https://ubuntu.com/security/CVE-2026-42014", "cve_description": "Changing the Security Officer PIN with gnutls_pkcs11_token_set_pin() with oldpin == NULL for a token lacking a protected authentication path led to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-42015", "url": "https://ubuntu.com/security/CVE-2026-42015", "cve_description": "Appending to a PKCS#12 bag that already contained 32 elements could write past the bag's internal array.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-5419", "url": "https://ubuntu.com/security/CVE-2026-5419", "cve_description": "The PKCS#7 padding check performed during decryption was not constant-time, potentially leaking information about the padding bytes through timing differences.", "cve_priority": "medium", "cve_public_date": "2026-04-30" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-33846", "url": "https://ubuntu.com/security/CVE-2026-33846", "cve_description": "A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.", "cve_priority": "medium", "cve_public_date": "2026-05-04 10:15:00 UTC" }, { "cve": "CVE-2026-42009", "url": "https://ubuntu.com/security/CVE-2026-42009", "cve_description": "A flaw was found in gnutls. A remote attacker could exploit an issue in the Datagram Transport Layer Security (DTLS) packet reordering logic. The comparator function, responsible for ordering DTLS packets by sequence numbers, did not correctly handle packets with duplicate sequence numbers. This could lead to unstable packet ordering or undefined behavior, resulting in a denial of service.", "cve_priority": "medium", "cve_public_date": "2026-05-18 13:16:00 UTC" }, { "cve": "CVE-2026-33845", "url": "https://ubuntu.com/security/CVE-2026-33845", "cve_description": "A flaw in GnuTLS DTLS handshake parsing allows malformed fragments with zero length and non-zero offset, leading to an integer underflow during reassembly and resulting in an out-of-bounds read. This issue is remotely exploitable and may cause information disclosure or denial of service.", "cve_priority": "medium", "cve_public_date": "2026-04-30 18:16:00 UTC" }, { "cve": "CVE-2026-3832", "url": "https://ubuntu.com/security/CVE-2026-3832", "cve_description": "A flaw was found in gnutls. A remote attacker could exploit this vulnerability by presenting a specially crafted Online Certificate Status Protocol (OCSP) response during a TLS handshake. Due to a logic error in how gnutls processes multi-record OCSP responses, a client with OCSP verification enabled may incorrectly accept a revoked server certificate, potentially leading to a compromise of trust.", "cve_priority": "medium", "cve_public_date": "2026-04-30 18:16:00 UTC" }, { "cve": "CVE-2026-3833", "url": "https://ubuntu.com/security/CVE-2026-3833", "cve_description": "A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of `nameConstraints` labels, specifically for `dNSName` (DNS) or `rfc822Name` (email) constraints within `excludedSubtrees` or `permittedSubtrees`. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.", "cve_priority": "medium", "cve_public_date": "2026-04-30 18:16:00 UTC" }, { "cve": "CVE-2026-42011", "url": "https://ubuntu.com/security/CVE-2026-42011", "cve_description": "A flaw was found in gnutls. This vulnerability occurs because permitted name constraints were incorrectly ignored when previous Certificate Authorities (CAs) only had excluded name constraints. A remote attacker could exploit this to bypass critical name constraint checks during certificate validation. This bypass could lead to the acceptance of invalid certificates, potentially enabling spoofing or man-in-the-middle attacks against affected systems.", "cve_priority": "medium", "cve_public_date": "2026-05-07 15:16:00 UTC" }, { "cve": "CVE-2026-42010", "url": "https://ubuntu.com/security/CVE-2026-42010", "cve_description": "A flaw was found in gnutls. Servers configured with RSA-PSK (Rivest–Shamir–Adleman – Pre-Shared Key) wrongfully matched usernames containing a NUL character with truncated usernames. A remote attacker could exploit this by sending a specially crafted username, leading to an authentication bypass. This vulnerability allows an attacker to gain unauthorized access by circumventing the authentication process.", "cve_priority": "medium", "cve_public_date": "2026-05-07 12:16:00 UTC" }, { "cve": "CVE-2026-5260", "url": "https://ubuntu.com/security/CVE-2026-5260", "cve_description": "For a server using an RSA key backed by a PKCS#11 token, a client sending an extremely short premaster secret during an RSA key exchange could trigger a short heap overread.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-42012", "url": "https://ubuntu.com/security/CVE-2026-42012", "cve_description": "Certificates containing URI or SRV Subject Alternative Names would fall back to checking DNS hostnames against Common Name, allowing potential misuse of such certificates beyond their original purpose.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-42013", "url": "https://ubuntu.com/security/CVE-2026-42013", "cve_description": "Validation of certificates with oversized Subject Alternative Names would fall back to checking DNS hostnames against Common Name.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-42014", "url": "https://ubuntu.com/security/CVE-2026-42014", "cve_description": "Changing the Security Officer PIN with gnutls_pkcs11_token_set_pin() with oldpin == NULL for a token lacking a protected authentication path led to a use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-42015", "url": "https://ubuntu.com/security/CVE-2026-42015", "cve_description": "Appending to a PKCS#12 bag that already contained 32 elements could write past the bag's internal array.", "cve_priority": "medium", "cve_public_date": "2026-04-30" }, { "cve": "CVE-2026-5419", "url": "https://ubuntu.com/security/CVE-2026-5419", "cve_description": "The PKCS#7 padding check performed during decryption was not constant-time, potentially leaking information about the padding bytes through timing differences.", "cve_priority": "medium", "cve_public_date": "2026-04-30" } ], "log": [ "", " * SECURITY UPDATE: buffer overflow in DTLS handshake fragment reassembly", " - debian/patches/CVE-2026-33846-pre1.patch: buffers: shorten", " merge_handshake_packet using recv_buf in lib/buffers.c.", " - debian/patches/CVE-2026-33846.patch: buffers: add more checks to DTLS", " reassembly in lib/buffers.c.", " - CVE-2026-33846", " * SECURITY UPDATE: DTLS packets sequence number ordering issue", " - debian/patches/CVE-2026-42009-pre1.patch: buffers: match DTLS datagrams by", " sequence number in lib/buffers.c.", " - debian/patches/CVE-2026-42009-1.patch: lib/buffers: ensure packets have", " differing sequence numbers in lib/buffers.c.", " - debian/patches/CVE-2026-42009-2.patch: buffers: fix handshake_compare when", " sequence numbers match in lib/buffers.c.", " - CVE-2026-42009", " * SECURITY UPDATE: OOB read via malformed fragments with zero length and", " non-zero offset", " - debian/patches/CVE-2026-33845-pre1.patch: buffers: rename a variable in", " parse_handshake_header in lib/buffers.c.", " - debian/patches/CVE-2026-33845.patch: buffers: switch from end_offset over", " to frag_length in lib/buffers.c, lib/gnutls_int.h.", " - debian/patches/CVE-2026-33845-2.patch: buffers: simplify and tighten", " parse_handshake_header checks in lib/buffers.c.", " - CVE-2026-33845", " * SECURITY UPDATE: malformed OCSP response issue", " - debian/patches/CVE-2026-3832-pre1.patch: iterate ocsp response records", " for matching certificate in doc/examples/ex-ocsp-client.c,", " lib/cert-session.c, lib/ocsp-api.c, src/ocsptool-common.c.", " - debian/patches/CVE-2026-3832-pre2.patch: fix formatting in", " doc/examples/ex-ocsp-client.c, lib/cert-session.c, lib/ocsp-api.c,", " src/ocsptool-common.c.", " - debian/patches/CVE-2026-3832.patch: cert-session: fix multi-entry OCSP", " revocation bypass in lib/cert-session.c.", " - CVE-2026-3832", " * SECURITY UPDATE: policy bypass via x509 case-sensitive comparisons", " - debian/patches/CVE-2026-3833.patch: x509/name-constraints: compare domain", " names case-insensitive in lib/x509/name_constraints.c.", " - CVE-2026-3833", " * SECURITY UPDATE: permitted name constrains were incorrectly ignored", " - debian/patches/CVE-2026-42011.patch: x509/name_constraints: fix", " intersecting empty constraints in lib/x509/name_constraints.c.", " - CVE-2026-42011", " * SECURITY UPDATE: ", " - debian/patches/CVE-2026-42010.patch: lib/auth/rsa_psk: fix binary PSK", " identity lookup in lib/auth/rsa_psk.c.", " - CVE-2026-42010", " * SECURITY UPDATE: incorrect username parsing with NUL characters", " - debian/patches/CVE-2026-5260-1.patch: lib/auth/rsa: check that ciphertext", " matches the modulus size in lib/auth/rsa.c, lib/auth/rsa_psk.c.", " - debian/patches/CVE-2026-5260-2.patch: lib/pkcs11_privkey: guard against", " overreading on short ciphertexts in lib/pkcs11_privkey.c.", " - CVE-2026-5260", " * SECURITY UPDATE: ", " - debian/patches/CVE-2026-42012-pre1.patch: x509/hostname-verify: refactor", " and simplify CN fallback logic in lib/x509/hostname-verify.c.", " - debian/patches/CVE-2026-42012-pre2.patch: x509: add bare-bones awareness", " of SRV virtual SAN in lib/includes/gnutls/gnutls.h.in, lib/x509/common.h,", " lib/x509/name_constraints.c, lib/x509/output.c, lib/x509/virt-san.c,", " lib/x509/x509.c.", " - debian/patches/CVE-2026-42012-pre3.patch: datum, mem, str: add helper", " functions to steal pointers in lib/datum.h, lib/mem.h, lib/str.h.", " - debian/patches/CVE-2026-42012.patch: x509/hostname-verify: make URI/SRV", " SAN preclude CN fallback in lib/x509/hostname-verify.c.", " - CVE-2026-42012", " * SECURITY UPDATE: incorrect URI or SRV Subject Alternative Names checking", " - debian/patches/CVE-2026-42013-pre1.patch: x509/email-verify: call", " fallback DN fallback in lib/x509/email-verify.c.", " - debian/patches/CVE-2026-42013.patch: x509: prevent fallback on oversized", " SAN in lib/x509/email-verify.c, lib/x509/hostname-verify.c.", " - CVE-2026-42013", " * SECURITY UPDATE: UaF when changing the Security Officer PIN", " - debian/patches/CVE-2026-42014.patch: pkcs11_write: fix UAF and leak in", " gnutls_pkcs11_token_set_pin in lib/pkcs11_write.c.", " - CVE-2026-42014", " * SECURITY UPDATE: buffer overflow when appending to a PKCS#12 bag", " - debian/patches/CVE-2026-42015.patch: x509/pkcs12_bag: fix off-by-one in", " bag element bounds check in lib/x509/pkcs12_bag.c.", " - CVE-2026-42015", " * SECURITY UPDATE: non constant-time PKCS#7 padding check", " - debian/patches/CVE-2026-5419.patch: gnutls_cipher_decrypt3: make PKCS#7", " unpadding branch free in lib/crypto-api.c, lib/libgnutls.map,", " tests/Makefile.am, tests/pkcs7-pad.c.", " - debian/patches/CVE-2026-5419-2.patch: _gnutls_pkcs7_unpad: add missing", " declaration in lib/crypto-api.c.", " - CVE-2026-5419", "" ], "package": "gnutls28", "version": "3.8.3-1.1ubuntu3.6", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 08 May 2026 12:59:02 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libkmod2", "from_version": { "source_package_name": "kmod", "source_package_version": "31+20240202-2ubuntu7.1", "version": "31+20240202-2ubuntu7.1" }, "to_version": { "source_package_name": "kmod", "source_package_version": "31+20240202-2ubuntu7.2", "version": "31+20240202-2ubuntu7.2" }, "cves": [ { "cve": "CVE-2026-31431", "url": "https://ubuntu.com/security/CVE-2026-31431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2150743 ], "changes": [ { "cves": [ { "cve": "CVE-2026-31431", "url": "https://ubuntu.com/security/CVE-2026-31431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" } ], "log": [ "", " * Disable loading of algif_aead module to mitigate CVE-2026-31431", " (LP: #2150743)", " - debian/modprobe.d/disable-algif_aead.conf", "" ], "package": "kmod", "version": "31+20240202-2ubuntu7.2", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2150743 ], "author": "Marc Deslauriers ", "date": "Thu, 30 Apr 2026 08:32:11 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libnghttp2-14", "from_version": { "source_package_name": "nghttp2", "source_package_version": "1.59.0-1ubuntu0.2", "version": "1.59.0-1ubuntu0.2" }, "to_version": { "source_package_name": "nghttp2", "source_package_version": "1.59.0-1ubuntu0.3", "version": "1.59.0-1ubuntu0.3" }, "cves": [ { "cve": "CVE-2026-27135", "url": "https://ubuntu.com/security/CVE-2026-27135", "cve_description": "nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API `nghttp2_session_terminate_session` or `nghttp2_session_terminate_session2` is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-27135", "url": "https://ubuntu.com/security/CVE-2026-27135", "cve_description": "nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API `nghttp2_session_terminate_session` or `nghttp2_session_terminate_session2` is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service through assertion failure.", " - debian/patches/CVE-2026-27135-pre1.patch: Add iframe->state ==", " NGHTTP2_IB_IGN_ALL checks in lib/nghttp2_session.c.", " - debian/patches/CVE-2026-27135-pre2.patch: Add iframe->state ==", " NGHTTP2_IB_IGN_ALL checks in lib/nghttp2_session.c.", " - debian/patches/CVE-2026-27135.patch: Add iframe->state ==", " NGHTTP2_IB_IGN_ALL checks in lib/nghttp2_session.c.", " - debian/patches/CVE-2026-27135-post1.patch: Add iframe->state ==", " NGHTTP2_IB_IGN_ALL checks in lib/nghttp2_session.c.", " - CVE-2026-27135", "" ], "package": "nghttp2", "version": "1.59.0-1ubuntu0.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Mon, 27 Apr 2026 17:35:02 -0230" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpng16-16t64", "from_version": { "source_package_name": "libpng1.6", "source_package_version": "1.6.43-5ubuntu0.5", "version": "1.6.43-5ubuntu0.5" }, "to_version": { "source_package_name": "libpng1.6", "source_package_version": "1.6.43-5ubuntu0.6", "version": "1.6.43-5ubuntu0.6" }, "cves": [ { "cve": "CVE-2026-33416", "url": "https://ubuntu.com/security/CVE-2026-33416", "cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, `png_set_tRNS` and `png_set_PLTE` each alias a heap-allocated buffer between `png_struct` and `png_info`, sharing a single allocation across two structs with independent lifetimes. The `trans_alpha` aliasing has been present since at least libpng 1.0, and the `palette` aliasing since at least 1.2.1. Both affect all prior release lines `png_set_tRNS` sets `png_ptr->trans_alpha = info_ptr->trans_alpha` (256-byte buffer) and `png_set_PLTE` sets `info_ptr->palette = png_ptr->palette` (768-byte buffer). In both cases, calling `png_free_data` (with `PNG_FREE_TRNS` or `PNG_FREE_PLTE`) frees the buffer through `info_ptr` while the corresponding `png_ptr` pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to `png_set_tRNS` or `png_set_PLTE` has the same effect, because both functions call `png_free_data` internally before reallocating the `info_ptr` buffer. Version 1.6.56 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-03-26 17:16:00 UTC" }, { "cve": "CVE-2026-33636", "url": "https://ubuntu.com/security/CVE-2026-33636", "cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.6.36 through 1.6.55, an out-of-bounds read and write exists in libpng's ARM/AArch64 Neon-optimized palette expansion path. When expanding 8-bit paletted rows to RGB or RGBA, the Neon loop processes a final partial chunk without verifying that enough input pixels remain. Because the implementation works backward from the end of the row, the final iteration dereferences pointers before the start of the row buffer (OOB read) and writes expanded pixel data to the same underflowed positions (OOB write). This is reachable via normal decoding of attacker-controlled PNG input if Neon is enabled. Version 1.6.56 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-03-26 17:16:00 UTC" }, { "cve": "CVE-2026-34757", "url": "https://ubuntu.com/security/CVE-2026-34757", "cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.0.9 to before 1.6.57, passing a pointer obtained from png_get_PLTE, png_get_tRNS, or png_get_hIST back into the corresponding setter on the same png_struct/png_info pair causes the setter to read from freed memory and copy its contents into the replacement buffer. The setter frees the internal buffer before copying from the caller-supplied pointer, which now dangles. The freed region may contain stale data (producing silently corrupted chunk metadata) or data from subsequent heap allocations (leaking unrelated heap contents into the chunk struct). This vulnerability is fixed in 1.6.57.", "cve_priority": "medium", "cve_public_date": "2026-04-09 15:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-33416", "url": "https://ubuntu.com/security/CVE-2026-33416", "cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, `png_set_tRNS` and `png_set_PLTE` each alias a heap-allocated buffer between `png_struct` and `png_info`, sharing a single allocation across two structs with independent lifetimes. The `trans_alpha` aliasing has been present since at least libpng 1.0, and the `palette` aliasing since at least 1.2.1. Both affect all prior release lines `png_set_tRNS` sets `png_ptr->trans_alpha = info_ptr->trans_alpha` (256-byte buffer) and `png_set_PLTE` sets `info_ptr->palette = png_ptr->palette` (768-byte buffer). In both cases, calling `png_free_data` (with `PNG_FREE_TRNS` or `PNG_FREE_PLTE`) frees the buffer through `info_ptr` while the corresponding `png_ptr` pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to `png_set_tRNS` or `png_set_PLTE` has the same effect, because both functions call `png_free_data` internally before reallocating the `info_ptr` buffer. Version 1.6.56 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-03-26 17:16:00 UTC" }, { "cve": "CVE-2026-33636", "url": "https://ubuntu.com/security/CVE-2026-33636", "cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.6.36 through 1.6.55, an out-of-bounds read and write exists in libpng's ARM/AArch64 Neon-optimized palette expansion path. When expanding 8-bit paletted rows to RGB or RGBA, the Neon loop processes a final partial chunk without verifying that enough input pixels remain. Because the implementation works backward from the end of the row, the final iteration dereferences pointers before the start of the row buffer (OOB read) and writes expanded pixel data to the same underflowed positions (OOB write). This is reachable via normal decoding of attacker-controlled PNG input if Neon is enabled. Version 1.6.56 fixes the issue.", "cve_priority": "medium", "cve_public_date": "2026-03-26 17:16:00 UTC" }, { "cve": "CVE-2026-34757", "url": "https://ubuntu.com/security/CVE-2026-34757", "cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.0.9 to before 1.6.57, passing a pointer obtained from png_get_PLTE, png_get_tRNS, or png_get_hIST back into the corresponding setter on the same png_struct/png_info pair causes the setter to read from freed memory and copy its contents into the replacement buffer. The setter frees the internal buffer before copying from the caller-supplied pointer, which now dangles. The freed region may contain stale data (producing silently corrupted chunk metadata) or data from subsequent heap allocations (leaking unrelated heap contents into the chunk struct). This vulnerability is fixed in 1.6.57.", "cve_priority": "medium", "cve_public_date": "2026-04-09 15:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: use-after-free via shared buffers", " - debian/patches/CVE-2026-33416-1.patch: fix: Resolve use-after-free on", " `png_ptr->trans_alpha` in pngread.c, pngrutil.c, pngset.c, pngwrite.c.", " - debian/patches/CVE-2026-33416-2.patch: fix: Resolve use-after-free on", " `png_ptr->palette` in pngread.c, pngrtran.c, pngrutil.c, pngset.c,", " pngwrite.c.", " - debian/patches/CVE-2026-33416-3.patch: fix: Initialize tail bytes in", " `trans_alpha` buffers in pngset.c.", " - debian/patches/CVE-2026-33416-4.patch: fix: Sync `info_ptr->palette` after", " in-place transforms in pngrtran.c.", " - debian/patches/CVE-2026-33416-5.patch: fix: Sync `info_ptr->palette`", " unconditionally after in-place transforms in pngrtran.c.", " - CVE-2026-33416", " * SECURITY UPDATE: out-of-bounds access in ARM palette expansion path", " - debian/patches/CVE-2026-33636.patch: fix(arm): Resolve out-of-bounds", " read/write in NEON palette expansion in arm/palette_neon_intrinsics.c.", " - CVE-2026-33636", " * SECURITY UPDATE: getter-to-setter aliasing issues", " - debian/patches/CVE-2026-34757-1.patch: fix: Handle self-referencing", " pointers in getter-to-setter aliasing in CMakeLists.txt, Makefile.am,", " contrib/libtests/pnggetset.c, pngset.c, tests/pnggetset.", " - debian/patches/CVE-2026-34757-2.patch: fix: Handle getter-to-setter", " aliasing in append-style chunk setters in contrib/libtests/pnggetset.c,", " pngset.c.", " - debian/rules: set exec permissions on tests/pnggetset.", " - CVE-2026-34757", " * SECURITY UPDATE: integer overflow in rowbytes computation", " - debian/patches/rowbytes_overflow.patch: fix: Prevent integer overflow in", " rowbytes computation in AUTHORS, pngrtran.c.", " - No CVE number", "" ], "package": "libpng1.6", "version": "1.6.43-5ubuntu0.6", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 05 May 2026 15:06:14 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-110.110", "version": "6.8.0-110.110" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-117.117", "version": "6.8.0-117.117" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-117.117", "" ], "package": "linux-meta", "version": "6.8.0-117.117", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Tue, 05 May 2026 17:56:04 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-116.116", "" ], "package": "linux-meta", "version": "6.8.0-116.116", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Thu, 23 Apr 2026 00:35:57 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-114.114", "" ], "package": "linux-meta", "version": "6.8.0-114.114", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Wed, 15 Apr 2026 13:38:00 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-112.112", "" ], "package": "linux-meta", "version": "6.8.0-112.112", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Mehmet Basaran ", "date": "Sun, 12 Apr 2026 06:21:01 +0300" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-client", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.15", "version": "1:9.6p1-3ubuntu13.15" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.16", "version": "1:9.6p1-3ubuntu13.16" }, "cves": [ { "cve": "CVE-2026-35385", "url": "https://ubuntu.com/security/CVE-2026-35385", "cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35386", "url": "https://ubuntu.com/security/CVE-2026-35386", "cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35387", "url": "https://ubuntu.com/security/CVE-2026-35387", "cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35388", "url": "https://ubuntu.com/security/CVE-2026-35388", "cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35414", "url": "https://ubuntu.com/security/CVE-2026-35414", "cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.", "cve_priority": "medium", "cve_public_date": "2026-04-02 18:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-35385", "url": "https://ubuntu.com/security/CVE-2026-35385", "cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35386", "url": "https://ubuntu.com/security/CVE-2026-35386", "cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35387", "url": "https://ubuntu.com/security/CVE-2026-35387", "cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35388", "url": "https://ubuntu.com/security/CVE-2026-35388", "cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35414", "url": "https://ubuntu.com/security/CVE-2026-35414", "cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.", "cve_priority": "medium", "cve_public_date": "2026-04-02 18:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: unexpected scp setuid and setgid", " - debian/patches/CVE-2026-35385.patch: clear setuid/setgid bits from", " downloaded files in scp.c.", " - CVE-2026-35385", " * SECURITY UPDATE: command execution via shell metacharacters in username", " - debian/patches/CVE-2026-35386-pre1.patch: apply validity rules on", " ProxyJump usernames and hostnames in readconf.c, readconf.h, ssh.c.", " - debian/patches/CVE-2026-35386.patch: move username check earlier in", " ssh.c.", " - CVE-2026-35386", " * SECURITY UPDATE: use of unintended ECDSA algorithms", " - debian/patches/CVE-2026-35387_35414.patch: correctly match ECDSA", " signature algorithms against algorithm allowlists in", " auth2-hostbased.c, auth2-pubkey.c, sshconnect2.c.", " - CVE-2026-35387", " * SECURITY UPDATE: missing connection multiplexing confirmation", " - debian/patches/CVE-2026-35388.patch: add missing askpass check in", " mux.c.", " - CVE-2026-35388", " * SECURITY UPDATE: authorized_keys principals option mishandling", " - debian/patches/CVE-2026-35387_35414.patch: check for commas in", " auth2-pubkeyfile.c.", " - CVE-2026-35414", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Mon, 27 Apr 2026 20:29:48 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.15", "version": "1:9.6p1-3ubuntu13.15" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.16", "version": "1:9.6p1-3ubuntu13.16" }, "cves": [ { "cve": "CVE-2026-35385", "url": "https://ubuntu.com/security/CVE-2026-35385", "cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35386", "url": "https://ubuntu.com/security/CVE-2026-35386", "cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35387", "url": "https://ubuntu.com/security/CVE-2026-35387", "cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35388", "url": "https://ubuntu.com/security/CVE-2026-35388", "cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35414", "url": "https://ubuntu.com/security/CVE-2026-35414", "cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.", "cve_priority": "medium", "cve_public_date": "2026-04-02 18:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-35385", "url": "https://ubuntu.com/security/CVE-2026-35385", "cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35386", "url": "https://ubuntu.com/security/CVE-2026-35386", "cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35387", "url": "https://ubuntu.com/security/CVE-2026-35387", "cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35388", "url": "https://ubuntu.com/security/CVE-2026-35388", "cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35414", "url": "https://ubuntu.com/security/CVE-2026-35414", "cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.", "cve_priority": "medium", "cve_public_date": "2026-04-02 18:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: unexpected scp setuid and setgid", " - debian/patches/CVE-2026-35385.patch: clear setuid/setgid bits from", " downloaded files in scp.c.", " - CVE-2026-35385", " * SECURITY UPDATE: command execution via shell metacharacters in username", " - debian/patches/CVE-2026-35386-pre1.patch: apply validity rules on", " ProxyJump usernames and hostnames in readconf.c, readconf.h, ssh.c.", " - debian/patches/CVE-2026-35386.patch: move username check earlier in", " ssh.c.", " - CVE-2026-35386", " * SECURITY UPDATE: use of unintended ECDSA algorithms", " - debian/patches/CVE-2026-35387_35414.patch: correctly match ECDSA", " signature algorithms against algorithm allowlists in", " auth2-hostbased.c, auth2-pubkey.c, sshconnect2.c.", " - CVE-2026-35387", " * SECURITY UPDATE: missing connection multiplexing confirmation", " - debian/patches/CVE-2026-35388.patch: add missing askpass check in", " mux.c.", " - CVE-2026-35388", " * SECURITY UPDATE: authorized_keys principals option mishandling", " - debian/patches/CVE-2026-35387_35414.patch: check for commas in", " auth2-pubkeyfile.c.", " - CVE-2026-35414", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Mon, 27 Apr 2026 20:29:48 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-sftp-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.15", "version": "1:9.6p1-3ubuntu13.15" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.16", "version": "1:9.6p1-3ubuntu13.16" }, "cves": [ { "cve": "CVE-2026-35385", "url": "https://ubuntu.com/security/CVE-2026-35385", "cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35386", "url": "https://ubuntu.com/security/CVE-2026-35386", "cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35387", "url": "https://ubuntu.com/security/CVE-2026-35387", "cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35388", "url": "https://ubuntu.com/security/CVE-2026-35388", "cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35414", "url": "https://ubuntu.com/security/CVE-2026-35414", "cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.", "cve_priority": "medium", "cve_public_date": "2026-04-02 18:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-35385", "url": "https://ubuntu.com/security/CVE-2026-35385", "cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35386", "url": "https://ubuntu.com/security/CVE-2026-35386", "cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35387", "url": "https://ubuntu.com/security/CVE-2026-35387", "cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35388", "url": "https://ubuntu.com/security/CVE-2026-35388", "cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.", "cve_priority": "medium", "cve_public_date": "2026-04-02 17:16:00 UTC" }, { "cve": "CVE-2026-35414", "url": "https://ubuntu.com/security/CVE-2026-35414", "cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.", "cve_priority": "medium", "cve_public_date": "2026-04-02 18:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: unexpected scp setuid and setgid", " - debian/patches/CVE-2026-35385.patch: clear setuid/setgid bits from", " downloaded files in scp.c.", " - CVE-2026-35385", " * SECURITY UPDATE: command execution via shell metacharacters in username", " - debian/patches/CVE-2026-35386-pre1.patch: apply validity rules on", " ProxyJump usernames and hostnames in readconf.c, readconf.h, ssh.c.", " - debian/patches/CVE-2026-35386.patch: move username check earlier in", " ssh.c.", " - CVE-2026-35386", " * SECURITY UPDATE: use of unintended ECDSA algorithms", " - debian/patches/CVE-2026-35387_35414.patch: correctly match ECDSA", " signature algorithms against algorithm allowlists in", " auth2-hostbased.c, auth2-pubkey.c, sshconnect2.c.", " - CVE-2026-35387", " * SECURITY UPDATE: missing connection multiplexing confirmation", " - debian/patches/CVE-2026-35388.patch: add missing askpass check in", " mux.c.", " - CVE-2026-35388", " * SECURITY UPDATE: authorized_keys principals option mishandling", " - debian/patches/CVE-2026-35387_35414.patch: check for commas in", " auth2-pubkeyfile.c.", " - CVE-2026-35414", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Mon, 27 Apr 2026 20:29:48 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "sed", "from_version": { "source_package_name": "sed", "source_package_version": "4.9-2build1", "version": "4.9-2build1" }, "to_version": { "source_package_name": "sed", "source_package_version": "4.9-2ubuntu0.24.04.1", "version": "4.9-2ubuntu0.24.04.1" }, "cves": [ { "cve": "CVE-2026-5958", "url": "https://ubuntu.com/security/CVE-2026-5958", "cve_description": "When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: 1. resolves symlink to its target and stores the resolved path for determining when output is written, 2. opens the original symlink path (not the resolved one) to read the file. Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process. This issue was fixed in version 4.10.", "cve_priority": "medium", "cve_public_date": "2026-04-20 12:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-5958", "url": "https://ubuntu.com/security/CVE-2026-5958", "cve_description": "When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: 1. resolves symlink to its target and stores the resolved path for determining when output is written, 2. opens the original symlink path (not the resolved one) to read the file. Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process. This issue was fixed in version 4.10.", "cve_priority": "medium", "cve_public_date": "2026-04-20 12:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: TOCTOU race in sed -i --follow-symlinks", " - debian/patches/CVE-2026-5958.patch: open the already-resolved path", " instead of re-traversing the symlink in sed/execute.c.", " - CVE-2026-5958", "" ], "package": "sed", "version": "4.9-2ubuntu0.24.04.1", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 17 Apr 2026 14:02:14 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "xxd", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.12", "version": "2:9.1.0016-1ubuntu7.12" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0016-1ubuntu7.13", "version": "2:9.1.0016-1ubuntu7.13" }, "cves": [ { "cve": "CVE-2026-41411", "url": "https://ubuntu.com/security/CVE-2026-41411", "cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.", "cve_priority": "medium", "cve_public_date": "2026-04-24 17:16:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-41411", "url": "https://ubuntu.com/security/CVE-2026-41411", "cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.", "cve_priority": "medium", "cve_public_date": "2026-04-24 17:16:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Command injection via backtick expansion in tag files", " - debian/patches/CVE-2026-41411.patch: Disallow backticks before attempting", " to expand filenames", " - CVE-2026-41411", "" ], "package": "vim", "version": "2:9.1.0016-1ubuntu7.13", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Federico Quattrin ", "date": "Tue, 05 May 2026 06:14:36 -0300" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-image-6.8.0-117-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-110.110", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-117.117", "version": "6.8.0-117.117" }, "cves": [], "launchpad_bugs_fixed": [ 1786013, 1786013, 1786013, 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-117.117", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-117.117", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Manuel Diewald ", "date": "Tue, 05 May 2026 17:56:13 +0200" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-116.116", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-116.116", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Thu, 23 Apr 2026 00:36:38 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-114.114", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-114.114", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Wed, 15 Apr 2026 13:38:33 +0300" }, { "cves": [], "log": [ "", " * Main version: 6.8.0-112.112", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-112.112", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Mehmet Basaran ", "date": "Sun, 12 Apr 2026 06:21:17 +0300" } ], "notes": "linux-image-6.8.0-117-generic version '6.8.0-117.117' (source package linux-signed version '6.8.0-117.117') was added. linux-image-6.8.0-117-generic version '6.8.0-117.117' has the same source package name, linux-signed, as removed package linux-image-6.8.0-110-generic. As such we can use the source package version of the removed package, '6.8.0-110.110', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-6.8.0-117-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-110.110", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-117.117", "version": "6.8.0-117.117" }, "cves": [ { "cve": "CVE-2026-31419", "url": "https://ubuntu.com/security/CVE-2026-31419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) 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) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31431", "url": "https://ubuntu.com/security/CVE-2026-31431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31533", "url": "https://ubuntu.com/security/CVE-2026-31533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.", "cve_priority": "medium", "cve_public_date": "2026-04-23 18:16:00 UTC" }, { "cve": "CVE-2026-31504", "url": "https://ubuntu.com/security/CVE-2026-31504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-23214", "url": "https://ubuntu.com/security/CVE-2026-23214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject new transactions if the fs is fully read-only [BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount: BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered. But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs. [CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do. However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions. [FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2026-23213", "url": "https://ubuntu.com/security/CVE-2026-23213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Disable MMIO access during SMU Mode 1 reset During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs. To prevent this, set the `no_hw_access` flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline. A memory barrier `smp_mb()` is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state. (cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2025-71225", "url": "https://ubuntu.com/security/CVE-2025-71225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: suspend array while updating raid_disks via sysfs In raid1_reshape(), freeze_array() is called before modifying the r1bio memory pool (conf->r1bio_pool) and conf->raid_disks, and unfreeze_array() is called after the update is completed. However, freeze_array() only waits until nr_sync_pending and (nr_pending - nr_queued) of all buckets reaches zero. When an I/O error occurs, nr_queued is increased and the corresponding r1bio is queued to either retry_list or bio_end_io_list. As a result, freeze_array() may unblock before these r1bios are released. This can lead to a situation where conf->raid_disks and the mempool have already been updated while queued r1bios, allocated with the old raid_disks value, are later released. Consequently, free_r1bio() may access memory out of bounds in put_all_bios() and release r1bios of the wrong size to the new mempool, potentially causing issues with the mempool as well. Since only normal I/O might increase nr_queued while an I/O error occurs, suspending the array avoids this issue. Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends the array. Therefore, we suspend the array when updating raid_disks via sysfs to avoid this issue too.", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2025-68823", "url": "https://ubuntu.com/security/CVE-2025-68823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: fix deadlock when reading partition table When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdev_open()), a deadlock[1] can occur: 1. bdev_open() grabs disk->open_mutex 2. The process issues read I/O to ublk backend to read partition table 3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks 4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation) 5. This eventually calls blkdev_release() from the same context 6. blkdev_release() tries to grab disk->open_mutex again 7. Deadlock: same task waiting for a mutex it already holds The fix is to run blk_update_request() and blk_mq_end_request() with bottom halves disabled. This forces blkdev_release() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock. [axboe: rewrite comment in ublk]", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-23191", "url": "https://ubuntu.com/security/CVE-2026-23191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23215", "url": "https://ubuntu.com/security/CVE-2026-23215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/vmware: Fix hypercall clobbers Fedora QA reported the following panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ... because the QEMU VMware mouse emulation is buggy, and clears the top 32 bits of %rdi that the kernel kept a pointer in. The QEMU vmmouse driver saves and restores the register state in a \"uint32_t data[6];\" and as a result restores the state with the high bits all cleared. RDI originally contained the value of a valid kernel stack address (0xff5eeb3240003e54). After the vmware hypercall it now contains 0x40003e54, and we get a page fault as a result when it is dereferenced. The proper fix would be in QEMU, but this works around the issue in the kernel to keep old setups working, when old kernels had not happened to keep any state in %rdi over the hypercall. In theory this same issue exists for all the hypercalls in the vmmouse driver; in practice it has only been seen with vmware_hypercall3() and vmware_hypercall4(). For now, just mark RDI/RSI as clobbered for those two calls. This should have a minimal effect on code generation overall as it should be rare for the compiler to want to make RDI/RSI live across hypercalls.", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2026-23182", "url": "https://ubuntu.com/security/CVE-2026-23182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra: Fix a memory leak in tegra_slink_probe() In tegra_slink_probe(), when platform_get_irq() fails, it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23190", "url": "https://ubuntu.com/security/CVE-2026-23190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: fix memory leak in acp3x pdm dma ops", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23254", "url": "https://ubuntu.com/security/CVE-2026-23254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix outer network offset The udp GRO complete stage assumes that all the packets inserted the RX have the `encapsulation` flag zeroed. Such assumption is not true, as a few H/W NICs can set such flag when H/W offloading the checksum for an UDP encapsulated traffic, the tun driver can inject GSO packets with UDP encapsulation and the problematic layout can also be created via a veth based setup. Due to the above, in the problematic scenarios, udp4_gro_complete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing. Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udp_gro_complete().", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23180", "url": "https://ubuntu.com/security/CVE-2026-23180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: add bounds check for if_id in IRQ handler The IRQ handler extracts if_id from the upper 16 bits of the hardware status register and uses it to index into ethsw->ports[] without validation. Since if_id can be any 16-bit value (0-65535) but the ports array is only allocated with sw_attr.num_ifs elements, this can lead to an out-of-bounds read potentially. Add a bounds check before accessing the array, consistent with the existing validation in dpaa2_switch_rx().", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23256", "url": "https://ubuntu.com/security/CVE-2026-23256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanup In setup_nic_devices(), the initialization loop jumps to the label setup_nic_dev_free on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak. Fix this by changing the loop to iterate from the current index i down to 0. Compile tested only. Issue found using code review.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23257", "url": "https://ubuntu.com/security/CVE-2026-23257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanup In setup_nic_devices(), the initialization loop jumps to the label setup_nic_dev_free on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak. Fix this by changing the loop to iterate from the current index i down to 0. Also, decrement i in the devlink_alloc failure path to point to the last successfully allocated index. Compile tested only. Issue found using code review.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23258", "url": "https://ubuntu.com/security/CVE-2026-23258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: Initialize netdev pointer before queue setup In setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq(). However, the pointer to this structure is stored in oct->props[i].netdev only after the calls to netif_set_real_num_rx_queues() and netif_set_real_num_tx_queues(). If either of these functions fails, setup_nic_devices() returns an error without freeing the allocated netdev. Since oct->props[i].netdev is still NULL at this point, the cleanup function liquidio_destroy_nic_device() will fail to find and free the netdev, resulting in a memory leak. Fix this by initializing oct->props[i].netdev before calling the queue setup functions. This ensures that the netdev is properly accessible for cleanup in case of errors. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23206", "url": "https://ubuntu.com/security/CVE-2026-23206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zero The driver allocates arrays for ports, FDBs, and filter blocks using kcalloc() with ethsw->sw_attr.num_ifs as the element count. When the device reports zero interfaces (either due to hardware configuration or firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10) instead of NULL. Later in dpaa2_switch_probe(), the NAPI initialization unconditionally accesses ethsw->ports[0]->netdev, which attempts to dereference ZERO_SIZE_PTR (address 0x10), resulting in a kernel panic. Add a check to ensure num_ifs is greater than zero after retrieving device attributes. This prevents the zero-sized allocations and subsequent invalid pointer dereference.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23204", "url": "https://ubuntu.com/security/CVE-2026-23204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23205", "url": "https://ubuntu.com/security/CVE-2026-23205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: fix memory leak in smb2_open_file() Reproducer: 1. server: directories are exported read-only 2. client: mount -t cifs //${server_ip}/export /mnt 3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct 4. client: umount /mnt 5. client: sleep 1 6. client: modprobe -r cifs The error message is as follows: ============================================================================= BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown() ----------------------------------------------------------------------------- Object 0x00000000d47521be @offset=14336 ... WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577 ... Call Trace: kmem_cache_destroy+0x94/0x190 cifs_destroy_request_bufs+0x3e/0x50 [cifs] cleanup_module+0x4e/0x540 [cifs] __se_sys_delete_module+0x278/0x400 __x64_sys_delete_module+0x5f/0x70 x64_sys_call+0x2299/0x2ff0 do_syscall_64+0x89/0x350 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs] WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23176", "url": "https://ubuntu.com/security/CVE-2026-23176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: toshiba_haps: Fix memory leaks in add/remove routines toshiba_haps_add() leaks the haps object allocated by it if it returns an error after allocating that object successfully. toshiba_haps_remove() does not free the object pointed to by toshiba_haps before clearing that pointer, so it becomes unreachable allocated memory. Address these memory leaks by using devm_kzalloc() for allocating the memory in question.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23216", "url": "https://ubuntu.com/security/CVE-2026-23216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count() In iscsit_dec_conn_usage_count(), the function calls complete() while holding the conn->conn_usage_lock. As soon as complete() is invoked, the waiter (such as iscsit_close_connection()) may wake up and proceed to free the iscsit_conn structure. If the waiter frees the memory before the current thread reaches spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function attempts to release a lock within the already-freed connection structure. Fix this by releasing the spinlock before calling complete().", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2026-23193", "url": "https://ubuntu.com/security/CVE-2026-23193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count() In iscsit_dec_session_usage_count(), the function calls complete() while holding the sess->session_usage_lock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsit_session structure immediately. This creates a race condition where the current thread may attempt to execute spin_unlock_bh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free. To resolve this, release the session_usage_lock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23260", "url": "https://ubuntu.com/security/CVE-2026-23260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: maple: free entry on mas_store_gfp() failure regcache_maple_write() allocates a new block ('entry') to merge adjacent ranges and then stores it with mas_store_gfp(). When mas_store_gfp() fails, the new 'entry' remains allocated and is never freed, leaking memory. Free 'entry' on the failure path; on success continue freeing the replaced neighbor blocks ('lower', 'upper').", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23179", "url": "https://ubuntu.com/security/CVE-2026-23179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready() When the socket is closed while in TCP_LISTEN a callback is run to flush all outstanding packets, which in turns calls nvmet_tcp_listen_data_ready() with the sk_callback_lock held. So we need to check if we are in TCP_LISTEN before attempting to get the sk_callback_lock() to avoid a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23261", "url": "https://ubuntu.com/security/CVE-2026-23261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: release admin tagset if init fails nvme_fabrics creates an NVMe/FC controller in following path: nvmf_dev_write() -> nvmf_create_ctrl() -> nvme_fc_create_ctrl() -> nvme_fc_init_ctrl() nvme_fc_init_ctrl() allocates the admin blk-mq resources right after nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the fail_ctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc. Check ctrl->ctrl.admin_tagset in the fail_ctrl path and call nvme_remove_admin_tag_set() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23178", "url": "https://ubuntu.com/security/CVE-2026-23178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report() `i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of data into `ihid->rawbuf`. The former can come from the userspace in the hidraw driver and is only bounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set `max_buffer_size` field of `struct hid_ll_driver` which we do not). The latter has size determined at runtime by the maximum size of different report types you could receive on any particular device and can be a much smaller value. Fix this by truncating `recv_len` to `ihid->bufsize - sizeof(__le16)`. The impact is low since access to hidraw devices requires root.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71268", "url": "https://ubuntu.com/security/CVE-2025-71268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reservation leak in some error paths when inserting inline extent If we fail to allocate a path or join a transaction, we return from __cow_file_range_inline() without freeing the reserved qgroup data, resulting in a leak. Fix this by ensuring we call btrfs_qgroup_free_data() in such cases.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71270", "url": "https://ubuntu.com/security/CVE-2025-71270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Enable exception fixup for specific ADE subcode This patch allows the LoongArch BPF JIT to handle recoverable memory access errors generated by BPF_PROBE_MEM* instructions. When a BPF program performs memory access operations, the instructions it executes may trigger ADEM exceptions. The kernel’s built-in BPF exception table mechanism (EX_TYPE_BPF) will generate corresponding exception fixup entries in the JIT compilation phase; however, the architecture-specific trap handling function needs to proactively call the common fixup routine to achieve exception recovery. do_ade(): fix EX_TYPE_BPF memory access exceptions for BPF programs, ensure safe execution. Relevant test cases: illegal address access tests in module_attach and subprogs_extable of selftests/bpf.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71220", "url": "https://ubuntu.com/security/CVE-2025-71220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: call ksmbd_session_rpc_close() on error path in create_smb2_pipe() When ksmbd_iov_pin_rsp() fails, we should call ksmbd_session_rpc_close().", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71222", "url": "https://ubuntu.com/security/CVE-2025-71222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: ensure skb headroom before skb_push This avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom is less than needed (typically 110 - 94 = 16 bytes).", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71224", "url": "https://ubuntu.com/security/CVE-2025-71224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: ocb: skip rx_no_sta when interface is not joined ieee80211_ocb_rx_no_sta() assumes a valid channel context, which is only present after JOIN_OCB. RX may run before JOIN_OCB is executed, in which case the OCB interface is not operational. Skip RX peer handling when the interface is not joined to avoid warnings in the RX path.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23262", "url": "https://ubuntu.com/security/CVE-2026-23262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: Fix stats report corruption on queue count change The driver and the NIC share a region in memory for stats reporting. The NIC calculates its offset into this region based on the total size of the stats region and the size of the NIC's stats. When the number of queues is changed, the driver's stats region is resized. If the queue count is increased, the NIC can write past the end of the allocated stats region, causing memory corruption. If the queue count is decreased, there is a gap between the driver and NIC stats, leading to incorrect stats reporting. This change fixes the issue by allocating stats region with maximum size, and the offset calculation for NIC stats is changed to match with the calculation of the NIC.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-38201", "url": "https://ubuntu.com/security/CVE-2025-38201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. Similar to: b541ba7d1f5a (\"netfilter: conntrack: clamp maximum hashtable size to INT_MAX\")", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2026-23198", "url": "https://ubuntu.com/security/CVE-2026-23198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't clobber irqfd routing type when deassigning irqfd When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone. As a bonus, checking that the irqfd is active provides a convenient location for documenting _why_ KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens *before* the eventfd is detached), it will no longer receive updates via kvm_irq_routing_update(), and so KVM could deliver an event using stale routing information (relative to KVM_SET_GSI_ROUTING returning to userspace). As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information. As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd. Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irq_bypass_data being NULL when read by avic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ end trace 0000000000000000 ]--- If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23264", "url": "https://ubuntu.com/security/CVE-2026-23264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"drm/amd: Check if ASPM is enabled from PCIe subsystem\" This reverts commit 7294863a6f01248d72b61d38478978d638641bee. This commit was erroneously applied again after commit 0ab5d711ec74 (\"drm/amd: Refactor `amdgpu_aspm` to be evaluated per device\") removed it, leading to very hard to debug crashes, when used with a system with two AMD GPUs of which only one supports ASPM. (cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080)", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23187", "url": "https://ubuntu.com/security/CVE-2026-23187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domains Fix out-of-range access of bc->domains in imx8m_blk_ctrl_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23148", "url": "https://ubuntu.com/security/CVE-2026-23148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference There is a race condition in nvmet_bio_done() that can cause a NULL pointer dereference in blk_cgroup_bio_start(): 1. nvmet_bio_done() is called when a bio completes 2. nvmet_req_complete() is called, which invokes req->ops->queue_response(req) 3. The queue_response callback can re-queue and re-submit the same request 4. The re-submission reuses the same inline_bio from nvmet_req 5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete) invokes bio_uninit() for inline_bio, which sets bio->bi_blkg to NULL 6. The re-submitted bio enters submit_bio_noacct_nocheck() 7. blk_cgroup_bio_start() dereferences bio->bi_blkg, causing a crash: BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blk_cgroup_bio_start+0x10/0xd0 Call Trace: submit_bio_noacct_nocheck+0x44/0x250 nvmet_bdev_execute_rw+0x254/0x370 [nvmet] process_one_work+0x193/0x3c0 worker_thread+0x281/0x3a0 Fix this by reordering nvmet_bio_done() to call nvmet_req_bio_put() BEFORE nvmet_req_complete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23166", "url": "https://ubuntu.com/security/CVE-2026-23166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues Add NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashes during resume from suspend when rings[q_idx]->q_vector is NULL. Tested adaptor: 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02) Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003] SR-IOV state: both disabled and enabled can reproduce this issue. kernel version: v6.18 Reproduce steps: Boot up and execute suspend like systemctl suspend or rtcwake. Log: <1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040 <1>[ 231.444052] #PF: supervisor read access in kernel mode <1>[ 231.444484] #PF: error_code(0x0000) - not-present page <6>[ 231.444913] PGD 0 P4D 0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170 <4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010 <4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000 <4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000 <4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[ 231.451629] PKRU: 55555554 <4>[ 231.452076] Call Trace: <4>[ 231.452549] <4>[ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice] <4>[ 231.453482] ice_resume+0xfd/0x220 [ice] <4>[ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10 <4>[ 231.454425] pci_pm_resume+0x8c/0x140 <4>[ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10 <4>[ 231.455347] dpm_run_callback+0x5f/0x160 <4>[ 231.455796] ? dpm_wait_for_superior+0x107/0x170 <4>[ 231.456244] device_resume+0x177/0x270 <4>[ 231.456708] dpm_resume+0x209/0x2f0 <4>[ 231.457151] dpm_resume_end+0x15/0x30 <4>[ 231.457596] suspend_devices_and_enter+0x1da/0x2b0 <4>[ 231.458054] enter_state+0x10e/0x570 Add defensive checks for both the ring pointer and its q_vector before dereferencing, allowing the system to resume successfully even when q_vectors are unmapped.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23151", "url": "https://ubuntu.com/security/CVE-2026-23151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix memory leak in set_ssp_complete Fix memory leak in set_ssp_complete() where mgmt_pending_cmd structures are not freed after being removed from the pending list. Commit 302a1f674c00 (\"Bluetooth: MGMT: Fix possible UAFs\") replaced mgmt_pending_foreach() calls with individual command handling but missed adding mgmt_pending_free() calls in both error and success paths of set_ssp_complete(). Other completion functions like set_le_complete() were fixed correctly in the same commit. This causes a memory leak of the mgmt_pending_cmd structure and its associated parameter data for each SSP command that completes. Add the missing mgmt_pending_free(cmd) calls in both code paths to fix the memory leak. Also fix the same issue in set_advertising_complete().", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23163", "url": "https://ubuntu.com/security/CVE-2026-23163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and ih2 interrupt ring buffers are not initialized. This is by design, as these secondary IH rings are only available on discrete GPUs. See vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when AMD_IS_APU is set. However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to get the timestamp of the last interrupt entry. When retry faults are enabled on APUs (noretry=0), this function is called from the SVM page fault recovery path, resulting in a NULL pointer dereference when amdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[]. The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu] Call Trace: amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu] svm_range_restore_pages+0xae5/0x11c0 [amdgpu] amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu] gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu] amdgpu_ih_process+0x84/0x100 [amdgpu] This issue was exposed by commit 1446226d32a4 (\"drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1\") which changed the default for Renoir APU from noretry=1 to noretry=0, enabling retry fault handling and thus exercising the buggy code path. Fix this by adding a check for ih1.ring_size before attempting to use it. Also restore the soft_ih support from commit dd299441654f (\"drm/amdgpu: Rework retry fault removal\"). This is needed if the hardware doesn't support secondary HW IH rings. v2: additional updates (Alex) (cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23159", "url": "https://ubuntu.com/security/CVE-2026-23159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: sched: Fix perf crash with new is_user_task() helper In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the task_struct mm field. If it was non NULL, it was a user task and if not it was a kernel task. But things have changed over time, and some kernel tasks now have their own mm field. An idea was made to instead test PF_KTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PF_KTHREAD directly. It was later found that not all kernel threads set PF_KTHREAD. The io-uring helpers instead set PF_USER_WORKER and this needed to be added as well. But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference. Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field. Instead of making this modification in every location, create a new is_user_task() helper function that does all the tests needed to know if it is safe to read the user space memory or not. [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2024-58096", "url": "https://ubuntu.com/security/CVE-2024-58096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-40039", "url": "https://ubuntu.com/security/CVE-2025-40039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix race condition in RPC handle list access The 'sess->rpc_handle_list' XArray manages RPC handles within a ksmbd session. Access to this list is intended to be protected by 'sess->rpc_lock' (an rw_semaphore). However, the locking implementation was flawed, leading to potential race conditions. In ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock before calling xa_store() and xa_erase(). Since these operations modify the XArray structure, a write lock is required to ensure exclusive access and prevent data corruption from concurrent modifications. Furthermore, ksmbd_session_rpc_method() accessed the list using xa_load() without holding any lock at all. This could lead to reading inconsistent data or a potential use-after-free if an entry is concurrently removed and the pointer is dereferenced. Fix these issues by: 1. Using down_write() and up_write() in ksmbd_session_rpc_open() to ensure exclusive access during XArray modification, and ensuring the lock is correctly released on error paths. 2. Adding down_read() and up_read() in ksmbd_session_rpc_method() to safely protect the lookup.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2026-23093", "url": "https://ubuntu.com/security/CVE-2026-23093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbd: fix dma_unmap_sg() nents The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23102", "url": "https://ubuntu.com/security/CVE-2026-23102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Fix restoration of SVE context When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL. (1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time. (2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length. Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear. For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23170", "url": "https://ubuntu.com/security/CVE-2026-23170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imx/tve: fix probe device leak Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23168", "url": "https://ubuntu.com/security/CVE-2026-23168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: flex_proportions: make fprop_new_period() hardirq safe Bernd has reported a lockdep splat from flexible proportions code that is essentially complaining about the following race: run_timer_softirq - we are in softirq context call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); ... blk_mq_end_request() \t blk_update_request() \t ext4_end_bio() \t folio_end_writeback() \t\t__wb_writeout_add() \t\t __fprop_add_percpu_max() \t\t if (unlikely(max_frac < FPROP_FRAC_BASE)) { \t\t fprop_fraction_percpu() \t\t\tseq = read_seqcount_begin(&p->sequence); \t\t\t - sees odd sequence so loops indefinitely Note that a deadlock like this is only possible if the bdi has configured maximum fraction of writeout throughput which is very rare in general but frequent for example for FUSE bdis. To fix this problem we have to make sure write section of the sequence counter is irqsafe.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23156", "url": "https://ubuntu.com/security/CVE-2026-23156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: fix error propagation in efivar_entry_get() efivar_entry_get() always returns success even if the underlying __efivar_entry_get() fails, masking errors. This may result in uninitialized heap memory being copied to userspace in the efivarfs_file_read() path. Fix it by returning the error from __efivar_entry_get().", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23167", "url": "https://ubuntu.com/security/CVE-2026-23167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix race between rfkill and nci_unregister_device(). syzbot reported the splat below [0] without a repro. It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill. nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev. The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister(). So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed. Let's unregister the device from rfkill first in nci_unregister_device(). Note that we cannot call nfc_unregister_device() before nci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23173", "url": "https://ubuntu.com/security/CVE-2026-23173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: TC, delete flows only for existing peers When deleting TC steering flows, iterate only over actual devcom peers instead of assuming all possible ports exist. This avoids touching non-existent peers and ensures cleanup is limited to devices the driver is currently connected to. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: mlx5e_tc_del_flow+0x46/0x270 [mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core] mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core] tc_setup_cb_reoffload+0x20/0x80 fl_reoffload+0x26f/0x2f0 [cls_flower] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] tcf_block_playback_offloads+0x9e/0x1c0 tcf_block_unbind+0x7b/0xd0 tcf_block_setup+0x186/0x1d0 tcf_block_offload_cmd.isra.0+0xef/0x130 tcf_block_offload_unbind+0x43/0x70 __tcf_block_put+0x85/0x160 ingress_destroy+0x32/0x110 [sch_ingress] __qdisc_destroy+0x44/0x100 qdisc_graft+0x22b/0x610 tc_get_qdisc+0x183/0x4d0 rtnetlink_rcv_msg+0x2d7/0x3d0 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x249/0x320 ? __alloc_skb+0x102/0x1f0 netlink_sendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1ef/0x230 ? copy_msghdr_from_user+0x6c/0xa0 ___sys_sendmsg+0x7f/0xc0 ? ___sys_recvmsg+0x8a/0xc0 ? __sys_sendto+0x119/0x180 __sys_sendmsg+0x61/0xb0 do_syscall_64+0x55/0x640 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764 RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23150", "url": "https://ubuntu.com/security/CVE-2026-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame(). syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO. ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup(). The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices. If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame(). Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm \"syz.0.17\", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm \"syz.0.17\", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23164", "url": "https://ubuntu.com/security/CVE-2026-23164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rocker: fix memory leak in rocker_world_port_post_fini() In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal. Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23172", "url": "https://ubuntu.com/security/CVE-2026-23172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: fix potential skb->frags overflow in RX path When receiving data in the DPMAIF RX path, the t7xx_dpmaif_set_frag_to_skb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow in skb_shinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior. This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf (\"mt76: fix array overflow on receiving too many fragments for a packet\"). The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects. Fix this by adding a bounds check before calling skb_add_rx_frag() to ensure nr_frags does not exceed MAX_SKB_FRAGS. The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23212", "url": "https://ubuntu.com/security/CVE-2026-23212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: annotate data-races around slave->last_rx slave->last_rx and slave->target_last_arp_rx[...] can be read and written locklessly. Add READ_ONCE() and WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 ... write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 br_netif_receive_skb net/bridge/br_input.c:30 [inline] NF_HOOK include/linux/netfilter.h:318 [inline] ... value changed: 0x0000000100005365 -> 0x0000000100005366", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2026-23160", "url": "https://ubuntu.com/security/CVE-2026-23160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeon_ep: Fix memory leak in octep_device_setup() In octep_device_setup(), if octep_ctrl_net_init() fails, the function returns directly without unmapping the mapped resources and freeing the allocated configuration memory. Fix this by jumping to the unsupported_dev label, which performs the necessary cleanup. This aligns with the error handling logic of other paths in this function. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23146", "url": "https://ubuntu.com/security/CVE-2026-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23394", "url": "https://ubuntu.com/security/CVE-2026-23394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-38591", "url": "https://ubuntu.com/security/CVE-2025-38591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject narrower access to pointer ctx fields The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the \"is_narrower_load\" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper \"invalid bpf_context access off=X size=Y\" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the \"Closes\" link below, which used to be about a different bug, fixed in commit fce7bd8e385a (\"bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()\"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2026-23035", "url": "https://ubuntu.com/security/CVE-2026-23035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails. Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a valid netdev. On mlx5e_remove: Check validity of priv->profile, before attempting to cleanup any resources that might be not there. This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure. $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 $ devlink dev reload pci/0000:00:03.0 ==> oops BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0 RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10 R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0 R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400 FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0 Call Trace: mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-22996", "url": "https://ubuntu.com/security/CVE-2026-22996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5e_dev and get mdev from the containing mlx5_adev aux device structure. This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure. $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 $ devlink dev reload pci/0000:00:03.0 ==> oops BUG: kernel NULL pointer dereference, address: 0000000000000520 #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: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_remove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23000", "url": "https://ubuntu.com/security/CVE-2026-23000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash on profile change rollback failure mlx5e_netdev_change_profile can fail to attach a new profile and can fail to rollback to old profile, in such case, we could end up with a dangling netdev with a fully reset netdev_priv. A retry to change profile, e.g. another attempt to call mlx5e_netdev_change_profile via switchdev mode change, will crash trying to access the now NULL priv->mdev. This fix allows mlx5e_netdev_change_profile() to handle previous failures and an empty priv, by not assuming priv is valid. Pass netdev and mdev to all flows requiring mlx5e_netdev_change_profile() and avoid passing priv. In mlx5e_netdev_change_profile() check if current priv is valid, and if not, just attach the new profile without trying to access the old one. This fixes the following oops, when enabling switchdev mode for the 2nd time after first time failure: ## Enabling switchdev mode first time: mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 ^^^^^^^^ mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) ## retry: Enabling switchdev mode 2nd time: mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload BUG: kernel NULL pointer dereference, address: 0000000000000038 #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: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_detach_netdev+0x3c/0x90 Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Call Trace: mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdfb8495047", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23053", "url": "https://ubuntu.com/security/CVE-2026-23053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a deadlock involving nfs_release_folio() Wang Zhaolong reports a deadlock involving NFSv4.1 state recovery waiting on kthreadd, which is attempting to reclaim memory by calling nfs_release_folio(). The latter cannot make progress due to state recovery being needed. It seems that the only safe thing to do here is to kick off a writeback of the folio, without waiting for completion, or else kicking off an asynchronous commit.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23050", "url": "https://ubuntu.com/security/CVE-2026-23050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix a deadlock when returning a delegation during open() Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935 The issue is that the delegreturn is being asked to wait for a layout return that cannot complete because a state recovery was initiated. The state recovery cannot complete until the open() finishes processing the delegations it was given. The solution is to propagate the existing flags that indicate a non-blocking call to the function pnfs_roc(), so that it knows not to wait in this situation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23005", "url": "https://ubuntu.com/security/CVE-2026-23005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1 When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel. E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's call to fpu_update_guest_xfd(). and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component): If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i). Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD. Therefore, XFD can only go out of sync with XSTATE_BV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features. [Move clea ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2024-58097", "url": "https://ubuntu.com/security/CVE-2024-58097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix RCU stall while reaping monitor destination ring While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id. However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash. kernel log: ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-68365", "url": "https://ubuntu.com/security/CVE-2025-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-37926", "url": "https://ubuntu.com/security/CVE-2025-37926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_session_rpc_open A UAF issue can occur due to a race condition between ksmbd_session_rpc_open() and __session_rpc_close(). Add rpc_lock to the session to protect it.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-23030", "url": "https://ubuntu.com/security/CVE-2026-23030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe() The for_each_available_child_of_node() calls of_node_put() to release child_np in each success loop. After breaking from the loop with the child_np has been released, the code will jump to the put_child label and will call the of_node_put() again if the devm_request_threaded_irq() fails. These cause a double free bug. Fix by returning directly to avoid the duplicate of_node_put().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23025", "url": "https://ubuntu.com/security/CVE-2026-23025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: prevent pcp corruption with SMP=n The kernel test robot has reported: BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: __dump_stack (lib/dump_stack.c:95) dump_stack_lvl (lib/dump_stack.c:123) dump_stack (lib/dump_stack.c:130) spin_dump (kernel/locking/spinlock_debug.c:71) do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?) _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138) __free_frozen_pages (mm/page_alloc.c:2973) ___free_pages (mm/page_alloc.c:5295) __free_pages (mm/page_alloc.c:5334) tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290) ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289) ? rcu_core (kernel/rcu/tree.c:?) rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcu_core_si (kernel/rcu/tree.c:2879) handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725) irq_exit_rcu (kernel/softirq.c:741) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052) RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194) free_pcppages_bulk (mm/page_alloc.c:1494) drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632) __drain_all_pages (mm/page_alloc.c:2731) drain_all_pages (mm/page_alloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork (arch/x86/kernel/process.c:164) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Matthew has analyzed the report and identified that in drain_page_zone() we are in a section protected by spin_lock(&pcp->lock) and then get an interrupt that attempts spin_trylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spin_trylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure. The problem has been introduced by commit 574907741599 (\"mm/page_alloc: leave IRQs enabled for per-cpu page allocations\"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spin_trylock() sections on SMP=n, but the need to prevent the nesting in spin_lock() has not been recognized. Fix it by introducing local wrappers that change the spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places that do spin_lock(&pcp->lock). [vbabka@suse.cz: add pcp_ prefix to the spin_lock_irqsave wrappers, per Steven]", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71186", "url": "https://ubuntu.com/security/CVE-2025-71186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: stm32: dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23078", "url": "https://ubuntu.com/security/CVE-2026-23078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23142", "url": "https://ubuntu.com/security/CVE-2026-23142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure When a DAMOS-scheme DAMON sysfs directory setup fails after setup of access_pattern/ directory, subdirectories of access_pattern/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked. Cleanup the directories under such failures.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23075", "url": "https://ubuntu.com/security/CVE-2026-23075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close(). Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-68725", "url": "https://ubuntu.com/security/CVE-2025-68725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d (\"gso: validate gso_type in GSO handlers\") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2026-23097", "url": "https://ubuntu.com/security/CVE-2026-23097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23108", "url": "https://ubuntu.com/security/CVE-2026-23108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23080", "url": "https://ubuntu.com/security/CVE-2026-23080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23061", "url": "https://ubuntu.com/security/CVE-2026-23061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23058", "url": "https://ubuntu.com/security/CVE-2026-23058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23085", "url": "https://ubuntu.com/security/CVE-2026-23085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23116", "url": "https://ubuntu.com/security/CVE-2026-23116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu For i.MX8MQ platform, the ADB in the VPUMIX domain has no separate reset and clock enable bits, but is ungated and reset together with the VPUs. So we can't reset G1 or G2 separately, it may led to the system hang. Remove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data. Let imx8mq_vpu_power_notifier() do really vpu reset.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23098", "url": "https://ubuntu.com/security/CVE-2026-23098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23063", "url": "https://ubuntu.com/security/CVE-2026-23063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: ensure safe queue release with state management Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23056", "url": "https://ubuntu.com/security/CVE-2026-23056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: implement mremap in uacce_vm_ops to return -EPERM The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23094", "url": "https://ubuntu.com/security/CVE-2026-23094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix isolate sysfs check condition uacce supports the device isolation feature. If the driver implements the isolate_err_threshold_read and isolate_err_threshold_write callback functions, uacce will create sysfs files now. Users can read and configure the isolation policy through sysfs. Currently, sysfs files are created as long as either isolate_err_threshold_read or isolate_err_threshold_write callback functions are present. However, accessing a non-existent callback function may cause the system to crash. Therefore, intercept the creation of sysfs if neither read nor write exists; create sysfs if either is supported, but intercept unsupported operations at the call site.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23096", "url": "https://ubuntu.com/security/CVE-2026-23096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23091", "url": "https://ubuntu.com/security/CVE-2026-23091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23088", "url": "https://ubuntu.com/security/CVE-2026-23088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash on synthetic stacktrace field usage When creating a synthetic event based on an existing synthetic event that had a stacktrace field and the new synthetic event used that field a kernel crash occurred: ~# cd /sys/kernel/tracing ~# echo 's:stack unsigned long stack[];' > dynamic_events ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/trigger The above creates a synthetic event that takes a stacktrace when a task schedules out in a non-running state and passes that stacktrace to the sched_switch event when that task schedules back in. It triggers the \"stack\" synthetic event that has a stacktrace as its field (called \"stack\"). ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/trigger The above makes another synthetic event called \"syscall_stack\" that attaches the first synthetic event (stack) to the sys_exit trace event and records the stacktrace from the stack event with the id of the system call that is exiting. When enabling this event (or using it in a historgram): ~# echo 1 > events/synthetic/syscall_stack/enable Produces a kernel crash! BUG: unable to handle page fault for address: 0000000000400010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 Call Trace: ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpstate+0x3e/0x90 ? _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 ? __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reason is that the stacktrace field is not labeled as such, and is treated as a normal field and not as a dynamic event that it is. In trace_event_raw_event_synth() the event is field is still treated as a dynamic array, but the retrieval of the data is considered a normal field, and the reference is just the meta data: // Meta data is retrieved instead of a dynamic array ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23090", "url": "https://ubuntu.com/security/CVE-2026-23090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: core: fix device reference leak on report present Slimbus devices can be allocated dynamically upon reception of report-present messages. Make sure to drop the reference taken when looking up already registered devices. Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23128", "url": "https://ubuntu.com/security/CVE-2026-23128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Set __nocfi on swsusp_arch_resume() A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*() and does not have a CFI hash, but swsusp_arch_resume() will attempt to verify the CFI hash when calling a copy of swsusp_arch_suspend_exit(). Given that there's an existing requirement that the entrypoint to swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text section, we cannot fix this by marking swsusp_arch_suspend_exit() with SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in swsusp_arch_resume(). Mark swsusp_arch_resume() as __nocfi to disable the CFI check. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23107", "url": "https://ubuntu.com/security/CVE-2026-23107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA The code to restore a ZA context doesn't attempt to allocate the task's sve_state before setting TIF_SME. Consequently, restoring a ZA context can place a task into an invalid state where TIF_SME is set but the task's sve_state is NULL. In legitimate but uncommon cases where the ZA signal context was NOT created by the kernel in the context of the same task (e.g. if the task is saved/restored with something like CRIU), we have no guarantee that sve_state had been allocated previously. In these cases, userspace can enter streaming mode without trapping while sve_state is NULL, causing a later NULL pointer dereference when the kernel attempts to store the register state: | # ./sigreturn-za | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000046 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x06: level 2 translation fault | Data abort info: | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00 | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000 | Internal error: Oops: 0000000096000046 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : sve_save_state+0x4/0xf0 | lr : fpsimd_save_user_state+0xb0/0x1c0 | sp : ffff80008070bcc0 | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000 | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020 | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0 | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440 | Call trace: | sve_save_state+0x4/0xf0 (P) | fpsimd_thread_switch+0x48/0x198 | __switch_to+0x20/0x1c0 | __schedule+0x36c/0xce0 | schedule+0x34/0x11c | exit_to_user_mode_loop+0x124/0x188 | el0_interrupt+0xc8/0xd8 | __el0_irq_handler_common+0x18/0x24 | el0t_64_irq_handler+0x10/0x1c | el0t_64_irq+0x198/0x19c | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ end trace 0000000000000000 ]--- Fix this by having restore_za_context() ensure that the task's sve_state is allocated, matching what we do when taking an SME trap. Any live SVE/SSVE state (which is restored earlier from a separate signal context) must be preserved, and hence this is not zeroed.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23073", "url": "https://ubuntu.com/security/CVE-2026-23073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory corruption due to not set vif driver data size The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed. The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure \"struct vif_priv\". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory. In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash. The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\", \"ip link set wlan0 down\" and the crash occurs. Fix this by setting the correct size of vif driver data, which is the size of \"struct vif_priv\", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23135", "url": "https://ubuntu.com/security/CVE-2026-23135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23133", "url": "https://ubuntu.com/security/CVE-2026-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-71200", "url": "https://ubuntu.com/security/CVE-2025-71200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode When operating in HS200 or HS400 timing modes, reducing the clock frequency below 52MHz will lead to link broken as the Rockchip DWC MSHC controller requires maintaining a minimum clock of 52MHz in these modes. Add a check to prevent illegal clock reduction through debugfs: root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock root@debian:/# [ 30.090146] mmc0: running CQE recovery mmc0: cqhci: Failed to halt mmc0: cqhci: spurious TCN for tag 0 WARNING: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24 Modules linked in: CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) Workqueue: kblockd blk_mq_run_work_fn pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cqhci_irq+0x254/0x818 lr : cqhci_irq+0x254/0x818 ...", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23089", "url": "https://ubuntu.com/security/CVE-2026-23089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23076", "url": "https://ubuntu.com/security/CVE-2026-23076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71199", "url": "https://ubuntu.com/security/CVE-2025-71199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23101", "url": "https://ubuntu.com/security/CVE-2026-23101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23064", "url": "https://ubuntu.com/security/CVE-2026-23064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: avoid possible NULL deref tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23086", "url": "https://ubuntu.com/security/CVE-2026-23086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: cap TX credit to local buffer size The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value. On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base. Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc. This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings. On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited. With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive. Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport. This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the \"remote window intersected with local policy\" behaviour that VMCI and Hyper-V already effectively have. [Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message]", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23069", "url": "https://ubuntu.com/security/CVE-2026-23069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential underflow in virtio_transport_get_credit() The credit calculation in virtio_transport_get_credit() uses unsigned arithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt); If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle. Reuse virtio_transport_has_space() which already handles this case and add a comment to make it clear why we are doing that. [Stefano: use virtio_transport_has_space() instead of duplicating the code] [Stefano: tweak the commit message]", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23119", "url": "https://ubuntu.com/security/CVE-2026-23119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: provide a net pointer to __skb_flow_dissect() After 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer. In the following case, syzbot was able to cook a bare skb. WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23084", "url": "https://ubuntu.com/security/CVE-2026-23084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function. However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer. To resolve this issue, it is necessary to pass the address of a stub variable to the function.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23124", "url": "https://ubuntu.com/security/CVE-2026-23124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: annotate data-race in ndisc_router_discovery() syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock [1] This looks fine, IFLA_INET6_RA_MTU is best effort. Add READ_ONCE()/WRITE_ONCE() to document the race. Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch. [1] BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... value changed: 0x00000000 -> 0xe5400659", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23121", "url": "https://ubuntu.com/security/CVE-2026-23121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: annotate data-race around dev->work dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000 -> 0x00000001", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23126", "url": "https://ubuntu.com/security/CVE-2026-23126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: fix a race issue related to the operation on bpf_bound_progs list The netdevsim driver lacks a protection mechanism for operations on the bpf_bound_progs list. When the nsim_bpf_create_prog() performs list_add_tail, it is possible that nsim_bpf_destroy_prog() is simultaneously performs list_del. Concurrent operations on the list may lead to list corruption and trigger a kernel crash as follows: [ 417.290971] kernel BUG at lib/list_debug.c:62! [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 417.291007] Workqueue: events bpf_prog_free_deferred [ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0 [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8 [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246 [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000 [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180 [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003 [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20 [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000 [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000 [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0 [ 417.291088] PKRU: 55555554 [ 417.291091] Call Trace: [ 417.291096] [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim] [ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80 [ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0 [ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0 [ 417.291178] process_one_work+0x18a/0x3a0 [ 417.291188] worker_thread+0x27b/0x3a0 [ 417.291197] ? __pfx_worker_thread+0x10/0x10 [ 417.291207] kthread+0xe5/0x120 [ 417.291214] ? __pfx_kthread+0x10/0x10 [ 417.291221] ret_from_fork+0x31/0x50 [ 417.291230] ? __pfx_kthread+0x10/0x10 [ 417.291236] ret_from_fork_asm+0x1a/0x30 [ 417.291246] Add a mutex lock, to prevent simultaneous addition and deletion operations on the list.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23059", "url": "https://ubuntu.com/security/CVE-2026-23059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Sanitize payload size to prevent member overflow In qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_size reported by firmware is used to calculate the copy length into item->iocb. However, the iocb member is defined as a fixed-size 64-byte array within struct purex_item. If the reported frame_size exceeds 64 bytes, subsequent memcpy calls will overflow the iocb member boundary. While extra memory might be allocated, this cross-member write is unsafe and triggers warnings under CONFIG_FORTIFY_SOURCE. Fix this by capping total_bytes to the size of the iocb member (64 bytes) before allocation and copying. This ensures all copies remain within the bounds of the destination structure member.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23110", "url": "https://ubuntu.com/security/CVE-2026-23110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Wake up the error handler when final completions race against each other The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance. First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count. This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands. Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task. This needs the call to scsi_host_busy() to be moved after host_failed is incremented to close the race condition.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23071", "url": "https://ubuntu.com/security/CVE-2026-23071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner. Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23068", "url": "https://ubuntu.com/security/CVE-2026-23068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-sprd-adi: Fix double free in probe error path The driver currently uses spi_alloc_host() to allocate the controller but registers it using devm_spi_register_controller(). If devm_register_restart_handler() fails, the code jumps to the put_ctlr label and calls spi_controller_put(). However, since the controller was registered via a devm function, the device core will automatically call spi_controller_put() again when the probe fails. This results in a double-free of the spi_controller structure. Fix this by switching to devm_spi_alloc_host() and removing the manual spi_controller_put() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23123", "url": "https://ubuntu.com/security/CVE-2026-23123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: debugfs: initialize src_node and dst_node to empty strings The debugfs_create_str() API assumes that the string pointer is either NULL or points to valid kmalloc() memory. Leaving the pointer uninitialized can cause problems. Initialize src_node and dst_node to empty strings before creating the debugfs entries to guarantee that reads and writes are safe.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2025-71198", "url": "https://ubuntu.com/security/CVE-2025-71198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL event_spec field, indicating support for IIO events. However, event detection is not supported for all sensors, and if userspace tries to configure accelerometer wakeup events on a sensor device that does not support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL pointer when trying to write to the wakeup register. Define an additional struct iio_chan_spec array whose members have a NULL event_spec field, and use this array instead of st_lsm6dsx_acc_channels for sensors without event detection capability.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23113", "url": "https://ubuntu.com/security/CVE-2026-23113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23062", "url": "https://ubuntu.com/security/CVE-2026-23062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs attributes: 1. Off-by-one error: The loop condition used '<=' instead of '<', causing access beyond array bounds. Since array indices are 0-based and go from 0 to instances_count-1, the loop should use '<'. 2. Missing NULL check: The code dereferenced attr_name_kobj->name without checking if attr_name_kobj was NULL, causing a null pointer dereference in min_length_show() and other attribute show functions. The panic occurred when fwupd tried to read BIOS configuration attributes: Oops: general protection fault [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg] Add a NULL check for attr_name_kobj before dereferencing and corrects the loop boundary to match the pattern used elsewhere in the driver.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23131", "url": "https://ubuntu.com/security/CVE-2026-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names The hp-bioscfg driver attempts to register kobjects with empty names when the HP BIOS returns attributes with empty name strings. This causes multiple kernel warnings: kobject: (00000000135fb5e6): attempted to be registered with empty name! WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310 Add validation in hp_init_bios_buffer_attribute() to check if the attribute name is empty after parsing it from the WMI buffer. If empty, log a debug message and skip registration of that attribute, allowing the module to continue processing other valid attributes.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23087", "url": "https://ubuntu.com/security/CVE-2026-23087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71197", "url": "https://ubuntu.com/security/CVE-2025-71197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: therm: Fix off-by-one buffer overflow in alarms_store The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23105", "url": "https://ubuntu.com/security/CVE-2026-23105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23103", "url": "https://ubuntu.com/security/CVE-2026-23103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23120", "url": "https://ubuntu.com/security/CVE-2026-23120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23083", "url": "https://ubuntu.com/security/CVE-2026-23083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23095", "url": "https://ubuntu.com/security/CVE-2026-23095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm \"syz.0.17\", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23125", "url": "https://ubuntu.com/security/CVE-2026-23125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23099", "url": "https://ubuntu.com/security/CVE-2026-23099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: limit BOND_MODE_8023AD to Ethernet devices BOND_MODE_8023AD makes sense for ARPHRD_ETHER only. syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497 CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 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 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71194", "url": "https://ubuntu.com/security/CVE-2025-71194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans(). This can lead to a deadlock scenario involving two transactions and pending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!) Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30 Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71185", "url": "https://ubuntu.com/security/CVE-2025-71185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23026", "url": "https://ubuntu.com/security/CVE-2026-23026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config() Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71188", "url": "https://ubuntu.com/security/CVE-2025-71188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71163", "url": "https://ubuntu.com/security/CVE-2025-71163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix device leaks on compat bind and unbind Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71189", "url": "https://ubuntu.com/security/CVE-2025-71189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw: dmamux: fix OF node leak on route allocation failure Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71190", "url": "https://ubuntu.com/security/CVE-2025-71190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: bcm-sba-raid: fix device leak on probe Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71191", "url": "https://ubuntu.com/security/CVE-2025-71191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()\") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23049", "url": "https://ubuntu.com/security/CVE-2026-23049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work: \" WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 \" The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23144", "url": "https://ubuntu.com/security/CVE-2026-23144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked. Cleanup the directories under such failures.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23145", "url": "https://ubuntu.com/security/CVE-2026-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22997", "url": "https://ubuntu.com/security/CVE-2026-22997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23031", "url": "https://ubuntu.com/security/CVE-2026-23031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23032", "url": "https://ubuntu.com/security/CVE-2026-23032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: fix kmemleak by releasing references to fault configfs items When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk driver sets up fault injection support by creating the timeout_inject, requeue_inject, and init_hctx_fault_inject configfs items as children of the top-level nullbX configfs group. However, when the nullbX device is removed, the references taken to these fault-config configfs items are not released. As a result, kmemleak reports a memory leak, for example: unreferenced object 0xc00000021ff25c40 (size 32): comm \"mkdir\", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ec Fix this by explicitly releasing the references to the fault-config configfs items when dropping the reference to the top-level nullbX configfs group.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23033", "url": "https://ubuntu.com/security/CVE-2026-23033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71196", "url": "https://ubuntu.com/security/CVE-2025-71196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: stm32-usphyc: Fix off by one in probe() The \"index\" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements. So if it is equal to usbphyc->nphys then it is one element out of bounds. The \"index\" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug. Change the > to >=.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71193", "url": "https://ubuntu.com/security/CVE-2025-71193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qusb2: Fix NULL pointer dereference on early suspend Enabling runtime PM before attaching the QPHY instance as driver data can lead to a NULL pointer dereference in runtime PM callbacks that expect valid driver data. There is a small window where the suspend callback may run after PM runtime enabling and before runtime forbid. This causes a sporadic crash during boot: ``` Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1 [...] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPT Workqueue: pm pm_runtime_work pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2] lr : pm_generic_runtime_suspend+0x2c/0x44 [...] ``` Attach the QPHY instance as driver data before enabling runtime PM to prevent NULL pointer dereference in runtime PM callbacks. Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71162", "url": "https://ubuntu.com/security/CVE-2025-71162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71195", "url": "https://ubuntu.com/security/CVE-2025-71195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx: xdma: Fix regmap max_register The max_register field is assigned the size of the register memory region instead of the offset of the last register. The result is that reading from the regmap via debugfs can cause a segmentation fault: tail /sys/kernel/debug/regmap/xdma.1.auto/registers Unable to handle kernel paging request at virtual address ffff800082f70000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault [...] Call trace: regmap_mmio_read32le+0x10/0x30 _regmap_bus_reg_read+0x74/0xc0 _regmap_read+0x68/0x198 regmap_read+0x54/0x88 regmap_read_debugfs+0x140/0x380 regmap_map_read_file+0x30/0x48 full_proxy_read+0x68/0xc8 vfs_read+0xcc/0x310 ksys_read+0x7c/0x120 __arm64_sys_read+0x24/0x40 invoke_syscall.constprop.0+0x64/0x108 do_el0_svc+0xb0/0xd8 el0_svc+0x38/0x130 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 Code: aa1e03e9 d503201f f9400000 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- note: tail[1217] exited with irqs disabled note: tail[1217] exited with preempt_count 1 Segmentation fault", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23006", "url": "https://ubuntu.com/security/CVE-2026-23006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tlv320adcx140: fix null pointer The \"snd_soc_component\" in \"adcx140_priv\" was only used once but never set. It was only used for reaching \"dev\" which is already present in \"adcx140_priv\".", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22999", "url": "https://ubuntu.com/security/CVE-2026-22999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23010", "url": "https://ubuntu.com/security/CVE-2026-23010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix use-after-free in inet6_addr_del(). syzbot reported use-after-free of inet6_ifaddr in inet6_addr_del(). [0] The cited commit accidentally moved ipv6_del_addr() for mngtmpaddr before reading its ifp->flags for temporary addresses in inet6_addr_del(). Let's move ipv6_del_addr() down to fix the UAF. [0]: BUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593 CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 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 inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f164cf8f749 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:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749 RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003 RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 Allocated by task 9593: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6099: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2540 [inline] slab_free_freelist_hook mm/slub.c:2569 [inline] slab_free_bulk mm/slub.c:6696 [inline] kmem_cache_free_bulk mm/slub.c:7383 [inline] kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362 kfree_bulk include/linux/slab.h:830 [inline] kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523 kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline] kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801 process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257 process_scheduled_works kernel/workqu ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23054", "url": "https://ubuntu.com/security/CVE-2026-23054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hv_netvsc: reject RSS hash key programming without RX indirection table RSS configuration requires a valid RX indirection table. When the device reports a single receive queue, rndis_filter_device_add() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang. Fix this by gating netvsc_set_rxfh() on ndc->rx_table_sz and return -EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device capabilities and prevents incorrect behavior.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23011", "url": "https://ubuntu.com/security/CVE-2026-23011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device. [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23001", "url": "https://ubuntu.com/security/CVE-2026-23001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix possible UAF in macvlan_forward_source() Add RCU protection on (struct macvlan_source_entry)->vlan. Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts. This allows macvlan_forward_source() to skip over entries queued for freeing. Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)). https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23003", "url": "https://ubuntu.com/security/CVE-2026-23003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1]. Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 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:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23141", "url": "https://ubuntu.com/security/CVE-2026-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22998", "url": "https://ubuntu.com/security/CVE-2026-22998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23037", "url": "https://ubuntu.com/security/CVE-2026-23037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: allow partial RX URB allocation to succeed When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked. As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error. Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23038", "url": "https://ubuntu.com/security/CVE-2026-23038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71184", "url": "https://ubuntu.com/security/CVE-2025-71184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix NULL dereference on root when tracing inode eviction When evicting an inode the first thing we do is to setup tracing for it, which implies fetching the root's id. But in btrfs_evict_inode() the root might be NULL, as implied in the next check that we do in btrfs_evict_inode(). Hence, we either should set the ->root_objectid to 0 in case the root is NULL, or we move tracing setup after checking that the root is not NULL. Setting the rootid to 0 at least gives us the possibility to trace this call even in the case when the root is NULL, so that's the solution taken here.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71182", "url": "https://ubuntu.com/security/CVE-2025-71182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: make j1939_session_activate() fail if device is no longer registered syzbot is still reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 even after commit 93a27b5891b8 (\"can: j1939: add missing calls in NETDEV_UNREGISTER notification handler\") was added. A debug printk() patch found that j1939_session_activate() can succeed even after j1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER) has completed. Since j1939_cancel_active_session() is processed with the session list lock held, checking ndev->reg_state in j1939_session_activate() with the session list lock held can reliably close the race window.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71160", "url": "https://ubuntu.com/security/CVE-2025-71160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid chain re-validation if possible Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..] Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps). But there are cases where we could avoid revalidation. Consider: 1 input -> j2 -> j3 2 input -> j2 -> j3 3 input -> j1 -> j2 -> j3 Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3. This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size. We also need to update all reachable chains with the new largest observed call depth. Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains. For example, the masquerade expression can only be called from NAT postrouting base chains. Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22994", "url": "https://ubuntu.com/security/CVE-2026-22994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix reference count leak in bpf_prog_test_run_xdp() syzbot is reporting unregister_netdevice: waiting for sit0 to become free. Usage count = 2 problem. A debug printk() patch found that a refcount is obtained at xdp_convert_md_to_buff() from bpf_prog_test_run_xdp(). According to commit ec94670fcb3b (\"bpf: Support specifying ingress via xdp_md context in BPF_PROG_TEST_RUN\"), the refcount obtained by xdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md(). Therefore, we can consider that the error handling path introduced by commit 1c1949982524 (\"bpf: introduce frags support to bpf_prog_test_run_xdp()\") forgot to call xdp_convert_buff_to_md().", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-23140", "url": "https://ubuntu.com/security/CVE-2026-23140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Subtract size of xdp_frame from allowed metadata size The xdp_frame structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpf_test_run, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom). If userspace supplies such a large metadata size in live packet mode, the xdp_update_frame_from_buff() call in xdp_test_run_init_page() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff. The commit in the Fixes tag fixed a related bug where the second check in xdp_update_frame_from_buff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-71192", "url": "https://ubuntu.com/security/CVE-2025-71192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix a double free in snd_ac97_controller_register() If ac97_add_adapter() fails, put_device() is the correct way to drop the device reference. kfree() is not required. Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do the cleanup. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-02-04 16:16:00 UTC" }, { "cve": "CVE-2026-23021", "url": "https://ubuntu.com/security/CVE-2026-23021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: fix memory leak in update_eth_regs_async() When asynchronously writing to the device registers and if usb_submit_urb() fail, the code fail to release allocated to this point resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-22976", "url": "https://ubuntu.com/security/CVE-2026-22976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset `qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the class itself is active. Two qfq_class objects may point to the same leaf_qdisc. This happens when: 1. one QFQ qdisc is attached to the dev as the root qdisc, and 2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get() / qdisc_put()) and is pending to be destroyed, as in function tc_new_tfilter. When packets are enqueued through the root QFQ qdisc, the shared leaf_qdisc->q.qlen increases. At the same time, the second QFQ qdisc triggers qdisc_put and qdisc_destroy: the qdisc enters qfq_reset() with its own q->q.qlen == 0, but its class's leaf qdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivate an inactive aggregate and trigger a null-deref in qfq_deactivate_agg: [ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 0.903571] #PF: supervisor write access in kernel mode [ 0.903860] #PF: error_code(0x0002) - not-present page [ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0 [ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI [ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE [ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2)) [ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0 Code starting with the faulting instruction =========================================== 0:\t0f 84 4d 01 00 00 \tje 0x153 6:\t48 89 70 18 \tmov %rsi,0x18(%rax) a:\t8b 4b 10 \tmov 0x10(%rbx),%ecx d:\t48 c7 c2 ff ff ff ff \tmov $0xffffffffffffffff,%rdx 14:\t48 8b 78 08 \tmov 0x8(%rax),%rdi 18:\t48 d3 e2 \tshl %cl,%rdx 1b:\t48 21 f2 \tand %rsi,%rdx 1e:\t48 2b 13 \tsub (%rbx),%rdx 21:\t48 8b 30 \tmov (%rax),%rsi 24:\t48 d3 ea \tshr %cl,%rdx 27:\t8b 4b 18 \tmov 0x18(%rbx),%ecx \t... [ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246 [ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000 [ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000 [ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000 [ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880 [ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000 [ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0 [ 0.910247] PKRU: 55555554 [ 0.910391] Call Trace: [ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485) [ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036) [ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076) [ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447) [ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) [ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861) [ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550) [ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) [ 0.912296] ? __alloc_skb (net/core/skbuff.c:706) [ 0.912484] netlink_sendmsg (net/netlink/af ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-21 07:16:00 UTC" }, { "cve": "CVE-2026-22979", "url": "https://ubuntu.com/security/CVE-2026-22979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix memory leak in skb_segment_list for GRO packets When skb_segment_list() is called during packet forwarding, it handles packets that were aggregated by the GRO engine. Historically, the segmentation logic in skb_segment_list assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments. Prior to commit ed4cccef64c1 (\"gro: fix ownership transfer\"), this truesize subtraction in skb_segment_list() was valid because fragments still carry a reference to the original socket. However, commit ed4cccef64c1 (\"gro: fix ownership transfer\") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skb_segment_list() was never updated. As a result, the current code unconditionally adds each fragment's truesize to delta_truesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes sk_wmem_alloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak. The leak can be observed via KMEMLEAK when tearing down the networking environment: unreferenced object 0xffff8881e6eb9100 (size 2048): comm \"ping\", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0 Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST packets constructed by GRO, the truesize adjustment is removed. The call to skb_release_head_state() must be preserved. As documented in commit cf673ed0e057 (\"net: fix fraglist segmentation reference count leak\"), it is still required to correctly drop references to SKB extensions that may be overwritten during __copy_skb_header().", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22977", "url": "https://ubuntu.com/security/CVE-2026-22977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sock: fix hardened usercopy panic in sock_recv_errqueue skbuff_fclone_cache was created without defining a usercopy region, [1] unlike skbuff_head_cache which properly whitelists the cb[] field. [2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is enabled and the kernel attempts to copy sk_buff.cb data to userspace via sock_recv_errqueue() -> put_cmsg(). The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone() (from skbuff_fclone_cache) [1] 2. The skb is cloned via skb_clone() using the pre-allocated fclone [3] 3. The cloned skb is queued to sk_error_queue for timestamp reporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE) 5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb [4] 6. __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist [5] When cloned skbs allocated from skbuff_fclone_cache are used in the socket error queue, accessing the sock_exterr_skb structure in skb->cb via put_cmsg() triggers a usercopy hardening violation: [ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)! [ 5.382796] kernel BUG at mm/usercopy.c:102! [ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7 [ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80 [ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490 [ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246 [ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74 [ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0 [ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74 [ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001 [ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00 [ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000 [ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0 [ 5.384903] PKRU: 55555554 [ 5.384903] Call Trace: [ 5.384903] [ 5.384903] __check_heap_object+0x9a/0xd0 [ 5.384903] __check_object_size+0x46c/0x690 [ 5.384903] put_cmsg+0x129/0x5e0 [ 5.384903] sock_recv_errqueue+0x22f/0x380 [ 5.384903] tls_sw_recvmsg+0x7ed/0x1960 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5.384903] ? schedule+0x6d/0x270 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5.384903] ? mutex_unlock+0x81/0xd0 [ 5.384903] ? __pfx_mutex_unlock+0x10/0x10 [ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10 [ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0 [ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5 The crash offset 296 corresponds to skb2->cb within skbuff_fclones: - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee) This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure. [1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885 [2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104 [3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566 [4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491 [5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719", "cve_priority": "medium", "cve_public_date": "2026-01-21 14:16:00 UTC" }, { "cve": "CVE-2026-22982", "url": "https://ubuntu.com/security/CVE-2026-22982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: Fix crash when adding interface under a lag Commit 15faa1f67ab4 (\"lan966x: Fix crash when adding interface under a lag\") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelot_set_aggr_pgids() function in the ocelot driver has similar logic and is susceptible to the same crash. This issue specifically affects the ocelot_vsc7514.c frontend, which leaves unused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports. Fix this by checking if the port pointer is valid before accessing it.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-23019", "url": "https://ubuntu.com/security/CVE-2026-23019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix NULL dereference on devlink_alloc() failure devlink_alloc() may return NULL on allocation failure, but prestera_devlink_alloc() unconditionally calls devlink_priv() on the returned pointer. This leads to a NULL pointer dereference if devlink allocation fails. Add a check for a NULL devlink pointer and return NULL early to avoid the crash.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23139", "url": "https://ubuntu.com/security/CVE-2026-23139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: update last_gc only when GC has been performed Currently last_gc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely. Update the last_gc value only when a GC has been actually performed.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-40149", "url": "https://ubuntu.com/security/CVE-2025-40149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-68803", "url": "https://ubuntu.com/security/CVE-2025-68803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: NFSv4 file creation neglects setting ACL An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: \"the ACL attribute is set as given\". The issue occurs in nfsd_create_setattr(), which calls nfsd_attrs_valid() to determine whether to call nfsd_setattr(). However, nfsd_attrs_valid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsd_setattr() is skipped, and the POSIX ACL is never applied to the inode. Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-23047", "url": "https://ubuntu.com/security/CVE-2026-23047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: make calc_target() set t->paused, not just clear it Currently calc_target() clears t->paused if the request shouldn't be paused anymore, but doesn't ever set t->paused even though it's able to determine when the request should be paused. Setting t->paused is left to __submit_request() which is fine for regular requests but doesn't work for linger requests -- since __submit_request() doesn't operate on linger requests, there is nowhere for lreq->t.paused to be set. One consequence of this is that watches don't get reestablished on paused -> unpaused transitions in cases where requests have been paused long enough for the (paused) unwatch request to time out and for the subsequent (re)watch request to enter the paused state. On top of the watch not getting reestablished, rbd_reregister_watch() gets stuck with rbd_dev->watch_mutex held: rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_wait It's waiting for lreq->reg_commit_wait to be completed, but for that to happen the respective request needs to end up on need_resend_linger list and be kicked when requests are unpaused. There is no chance for that if the request in question is never marked paused in the first place. The fact that rbd_dev->watch_mutex remains taken out forever then prevents the image from getting unmapped -- \"rbd unmap\" would inevitably hang in D state on an attempt to grab the mutex.", "cve_priority": "medium", "cve_public_date": "2026-02-04 16:16:00 UTC" }, { "cve": "CVE-2026-23136", "url": "https://ubuntu.com/security/CVE-2026-23136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reset sparse-read state in osd_fault() When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state. If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22992", "url": "https://ubuntu.com/security/CVE-2026-22992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: return the handler error from mon_handle_auth_done() Currently any error from ceph_auth_handle_reply_done() is propagated via finish_auth() but isn't returned from mon_handle_auth_done(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setup_crypto() and later lead to a NULL pointer dereference inside of prepare_auth_signature().", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22991", "url": "https://ubuntu.com/security/CVE-2026-22991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: make free_choose_arg_map() resilient to partial allocation free_choose_arg_map() may dereference a NULL pointer if its caller fails after a partial allocation. For example, in decode_choose_args(), if allocation of arg_map->args fails, execution jumps to the fail label and free_choose_arg_map() is called. Since arg_map->size is updated to a non-zero value before memory allocation, free_choose_arg_map() will iterate over arg_map->args and dereference a NULL pointer. To prevent this potential NULL pointer dereference and make free_choose_arg_map() more resilient, add checks for pointers before iterating.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22990", "url": "https://ubuntu.com/security/CVE-2026-22990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22984", "url": "https://ubuntu.com/security/CVE-2026-22984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]", "cve_priority": "high", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22978", "url": "https://ubuntu.com/security/CVE-2026-22978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: avoid kernel-infoleak from struct iw_point struct iw_point has a 32bit hole on 64bit arches. struct iw_point { void __user *pointer; /* Pointer to the data (in user space) */ __u16 length; /* number of fields or size in bytes */ __u16 flags; /* Optional params */ }; Make sure to zero the structure to avoid disclosing 32bits of kernel data to user space.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2025-71180", "url": "https://ubuntu.com/security/CVE-2025-71180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: counter: interrupt-cnt: Drop IRQF_NO_THREAD flag An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as CONFIG_PROVE_RAW_LOCK_NESTING warns: ============================= [ BUG: Invalid wait context ] 6.18.0-rc1+git... #1 ----------------------------- some-user-space-process/1251 is trying to lock: (&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter] other info that might help us debug this: context-{2:2} no locks held by some-user-space-process/.... stack backtrace: CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT Call trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq ... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an alternative to switching to raw_spinlock_t, because the latter would limit all potential nested locks to raw_spinlock_t only.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71183", "url": "https://ubuntu.com/security/CVE-2025-71183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: always detect conflicting inodes when logging inode refs After rename exchanging (either with the rename exchange operation or regular renames in multiple non-atomic steps) two inodes and at least one of them is a directory, we can end up with a log tree that contains only of the inodes and after a power failure that can result in an attempt to delete the other inode when it should not because it was not deleted before the power failure. In some case that delete attempt fails when the target inode is a directory that contains a subvolume inside it, since the log replay code is not prepared to deal with directory entries that point to root items (only inode items). 1) We have directories \"dir1\" (inode A) and \"dir2\" (inode B) under the same parent directory; 2) We have a file (inode C) under directory \"dir1\" (inode A); 3) We have a subvolume inside directory \"dir2\" (inode B); 4) All these inodes were persisted in a past transaction and we are currently at transaction N; 5) We rename the file (inode C), so at btrfs_log_new_name() we update inode C's last_unlink_trans to N; 6) We get a rename exchange for \"dir1\" (inode A) and \"dir2\" (inode B), so after the exchange \"dir1\" is inode B and \"dir2\" is inode A. During the rename exchange we call btrfs_log_new_name() for inodes A and B, but because they are directories, we don't update their last_unlink_trans to N; 7) An fsync against the file (inode C) is done, and because its inode has a last_unlink_trans with a value of N we log its parent directory (inode A) (through btrfs_log_all_parents(), called from btrfs_log_inode_parent()). 8) So we end up with inode B not logged, which now has the old name of inode A. At copy_inode_items_to_log(), when logging inode A, we did not check if we had any conflicting inode to log because inode A has a generation lower than the current transaction (created in a past transaction); 9) After a power failure, when replaying the log tree, since we find that inode A has a new name that conflicts with the name of inode B in the fs tree, we attempt to delete inode B... this is wrong since that directory was never deleted before the power failure, and because there is a subvolume inside that directory, attempting to delete it will fail since replay_dir_deletes() and btrfs_unlink_inode() are not prepared to deal with dir items that point to roots instead of inodes. When that happens the mount fails and we get a stack trace like the following: [87.2314] BTRFS info (device dm-0): start tree-log replay [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259 [87.2332] ------------[ cut here ]------------ [87.2338] BTRFS: Transaction aborted (error -2) [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2368] Modules linked in: btrfs loop dm_thin_pool (...) [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full) [87.2489] Tainted: [W]=WARN [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2538] Code: c0 89 04 24 (...) [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000 [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840 [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10 [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000 [87. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23020", "url": "https://ubuntu.com/security/CVE-2026-23020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: 3com: 3c59x: fix possible null dereference in vortex_probe1() pdev can be null and free_ring: can be called in 1297 with a null pdev.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-22980", "url": "https://ubuntu.com/security/CVE-2026-22980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: provide locking for v4_end_grace Writing to v4_end_grace can race with server shutdown and result in memory being accessed after it was freed - reclaim_str_hashtbl in particularly. We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is held while client_tracking_op->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4_end_grace, resulting in a deadlock. nfsd4_end_grace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4_end_grace() might access. However, we must be sure that writing to v4_end_grace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->client_lock. It is set only while it is safe to make client tracking calls, and v4_end_grace only schedules work while the flag is set with the spinlock held. So this patch adds a nfsd_net field \"client_tracking_active\" which is set as described. Another field \"grace_end_forced\", is set when v4_end_grace is written. After this is set, and providing client_tracking_active is set, the laundromat is scheduled. This \"grace_end_forced\" field bypasses other checks for whether the grace period has finished. This resolves a race which can result in use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2024-50004", "url": "https://ubuntu.com/security/CVE-2024-50004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35 [WHY & HOW] Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override to match HW spec. (cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2026-23274", "url": "https://ubuntu.com/security/CVE-2026-23274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.", "cve_priority": "medium", "cve_public_date": "2026-03-20 09:16:00 UTC" }, { "cve": "CVE-2026-23351", "url": "https://ubuntu.com/security/CVE-2026-23351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23231", "url": "https://ubuntu.com/security/CVE-2026-23231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.", "cve_priority": "high", "cve_public_date": "2026-03-04 13:15:00 UTC" }, { "cve": "CVE-2026-23209", "url": "https://ubuntu.com/security/CVE-2026-23209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23112", "url": "https://ubuntu.com/security/CVE-2026-23112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.", "cve_priority": "high", "cve_public_date": "2026-02-13 14:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2151070, 2150048, 2149766, 2149762, 2148397, 2146465, 2147982, 2147447, 2147400, 2147065, 2144577, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2145171, 2144060, 2144006, 2144914, 2143152, 2143083, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144380 ], "changes": [ { "cves": [ { "cve": "CVE-2026-31419", "url": "https://ubuntu.com/security/CVE-2026-31419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) 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) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================", "cve_priority": "medium", "cve_public_date": "2026-04-13 14:16:00 UTC" }, { "cve": "CVE-2026-31431", "url": "https://ubuntu.com/security/CVE-2026-31431", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.", "cve_priority": "high", "cve_public_date": "2026-04-22 09:16:00 UTC" }, { "cve": "CVE-2026-31533", "url": "https://ubuntu.com/security/CVE-2026-31533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.", "cve_priority": "medium", "cve_public_date": "2026-04-23 18:16:00 UTC" }, { "cve": "CVE-2026-31504", "url": "https://ubuntu.com/security/CVE-2026-31504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-117.117 -proposed tracker (LP: #2151070)", "", " * CVE-2026-31419", " - net: bonding: fix use-after-free in bond_xmit_broadcast()", "", " * CVE-2026-31431", " - crypto: scatterwalk - Backport memcpy_sglist()", " - crypto: algif_aead - use memcpy_sglist() instead of null skcipher", " - crypto: algif_aead - Revert to operating out-of-place", " - crypto: algif_aead - snapshot IV for async AEAD requests", " - crypto: authenc - use memcpy_sglist() instead of null skcipher", " - crypto: authencesn - Do not place hiseq at end of dst for out-of-place", " decryption", " - crypto: authencesn - Fix src offset when decrypting in-place", " - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl", " - crypto: algif_aead - Fix minimum RX size check for decryption", "", " * CVE-2026-31533", " - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption", "", " * CVE-2026-31504", " - net: fix fanout UAF in packet_release() via NETDEV_UP race", "" ], "package": "linux", "version": "6.8.0-117.117", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2151070 ], "author": "Manuel Diewald ", "date": "Tue, 05 May 2026 15:53:02 +0200" }, { "cves": [], "log": [ "", " * noble/linux: 6.8.0-116.116 -proposed tracker (LP: #2150048)", "", " * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)", " - Revert \"iommu: disable SVA when CONFIG_X86 is set\"", "", " * Revert \"netfilter: conntrack: fix erronous removal of offload bit\"", " (LP: #2149762)", " - Revert \"netfilter: conntrack: fix erronous removal of offload bit\"", "" ], "package": "linux", "version": "6.8.0-116.116", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2150048, 2149766, 2149762 ], "author": "Mehmet Basaran ", "date": "Thu, 23 Apr 2026 00:33:23 +0300" }, { "cves": [], "log": [ "", " * noble/linux: 6.8.0-114.114 -proposed tracker (LP: #2148397)", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465)", " - SAUCE: Fix skb_vlan_inet_prepare() usage", "" ], "package": "linux", "version": "6.8.0-114.114", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2148397, 2146465 ], "author": "Mehmet Basaran ", "date": "Wed, 15 Apr 2026 13:37:36 +0300" }, { "cves": [ { "cve": "CVE-2026-23214", "url": "https://ubuntu.com/security/CVE-2026-23214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject new transactions if the fs is fully read-only [BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount: BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered. But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs. [CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do. However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions. [FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2026-23213", "url": "https://ubuntu.com/security/CVE-2026-23213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Disable MMIO access during SMU Mode 1 reset During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs. To prevent this, set the `no_hw_access` flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline. A memory barrier `smp_mb()` is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state. (cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2025-71225", "url": "https://ubuntu.com/security/CVE-2025-71225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md: suspend array while updating raid_disks via sysfs In raid1_reshape(), freeze_array() is called before modifying the r1bio memory pool (conf->r1bio_pool) and conf->raid_disks, and unfreeze_array() is called after the update is completed. However, freeze_array() only waits until nr_sync_pending and (nr_pending - nr_queued) of all buckets reaches zero. When an I/O error occurs, nr_queued is increased and the corresponding r1bio is queued to either retry_list or bio_end_io_list. As a result, freeze_array() may unblock before these r1bios are released. This can lead to a situation where conf->raid_disks and the mempool have already been updated while queued r1bios, allocated with the old raid_disks value, are later released. Consequently, free_r1bio() may access memory out of bounds in put_all_bios() and release r1bios of the wrong size to the new mempool, potentially causing issues with the mempool as well. Since only normal I/O might increase nr_queued while an I/O error occurs, suspending the array avoids this issue. Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends the array. Therefore, we suspend the array when updating raid_disks via sysfs to avoid this issue too.", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2025-68823", "url": "https://ubuntu.com/security/CVE-2025-68823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: fix deadlock when reading partition table When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdev_open()), a deadlock[1] can occur: 1. bdev_open() grabs disk->open_mutex 2. The process issues read I/O to ublk backend to read partition table 3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks 4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation) 5. This eventually calls blkdev_release() from the same context 6. blkdev_release() tries to grab disk->open_mutex again 7. Deadlock: same task waiting for a mutex it already holds The fix is to run blk_update_request() and blk_mq_end_request() with bottom halves disabled. This forces blkdev_release() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock. [axboe: rewrite comment in ublk]", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-23191", "url": "https://ubuntu.com/security/CVE-2026-23191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix racy access at PCM trigger The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers. For addressing the UAF, this patch changes two things: - It covers the most of code in loopback_check_format() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23215", "url": "https://ubuntu.com/security/CVE-2026-23215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/vmware: Fix hypercall clobbers Fedora QA reported the following panic: BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmouse_report_events+0x13e/0x1b0 psmouse_handle_byte+0x15/0x60 ps2_interrupt+0x8a/0xd0 ... because the QEMU VMware mouse emulation is buggy, and clears the top 32 bits of %rdi that the kernel kept a pointer in. The QEMU vmmouse driver saves and restores the register state in a \"uint32_t data[6];\" and as a result restores the state with the high bits all cleared. RDI originally contained the value of a valid kernel stack address (0xff5eeb3240003e54). After the vmware hypercall it now contains 0x40003e54, and we get a page fault as a result when it is dereferenced. The proper fix would be in QEMU, but this works around the issue in the kernel to keep old setups working, when old kernels had not happened to keep any state in %rdi over the hypercall. In theory this same issue exists for all the hypercalls in the vmmouse driver; in practice it has only been seen with vmware_hypercall3() and vmware_hypercall4(). For now, just mark RDI/RSI as clobbered for those two calls. This should have a minimal effect on code generation overall as it should be rare for the compiler to want to make RDI/RSI live across hypercalls.", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2026-23182", "url": "https://ubuntu.com/security/CVE-2026-23182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: tegra: Fix a memory leak in tegra_slink_probe() In tegra_slink_probe(), when platform_get_irq() fails, it directly returns from the function with an error code, which causes a memory leak. Replace it with a goto label to ensure proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23190", "url": "https://ubuntu.com/security/CVE-2026-23190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: fix memory leak in acp3x pdm dma ops", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23254", "url": "https://ubuntu.com/security/CVE-2026-23254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix outer network offset The udp GRO complete stage assumes that all the packets inserted the RX have the `encapsulation` flag zeroed. Such assumption is not true, as a few H/W NICs can set such flag when H/W offloading the checksum for an UDP encapsulated traffic, the tun driver can inject GSO packets with UDP encapsulation and the problematic layout can also be created via a veth based setup. Due to the above, in the problematic scenarios, udp4_gro_complete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing. Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udp_gro_complete().", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23180", "url": "https://ubuntu.com/security/CVE-2026-23180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: add bounds check for if_id in IRQ handler The IRQ handler extracts if_id from the upper 16 bits of the hardware status register and uses it to index into ethsw->ports[] without validation. Since if_id can be any 16-bit value (0-65535) but the ports array is only allocated with sw_attr.num_ifs elements, this can lead to an out-of-bounds read potentially. Add a bounds check before accessing the array, consistent with the existing validation in dpaa2_switch_rx().", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23256", "url": "https://ubuntu.com/security/CVE-2026-23256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanup In setup_nic_devices(), the initialization loop jumps to the label setup_nic_dev_free on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak. Fix this by changing the loop to iterate from the current index i down to 0. Compile tested only. Issue found using code review.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23257", "url": "https://ubuntu.com/security/CVE-2026-23257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanup In setup_nic_devices(), the initialization loop jumps to the label setup_nic_dev_free on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak. Fix this by changing the loop to iterate from the current index i down to 0. Also, decrement i in the devlink_alloc failure path to point to the last successfully allocated index. Compile tested only. Issue found using code review.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23258", "url": "https://ubuntu.com/security/CVE-2026-23258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: Initialize netdev pointer before queue setup In setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq(). However, the pointer to this structure is stored in oct->props[i].netdev only after the calls to netif_set_real_num_rx_queues() and netif_set_real_num_tx_queues(). If either of these functions fails, setup_nic_devices() returns an error without freeing the allocated netdev. Since oct->props[i].netdev is still NULL at this point, the cleanup function liquidio_destroy_nic_device() will fail to find and free the netdev, resulting in a memory leak. Fix this by initializing oct->props[i].netdev before calling the queue setup functions. This ensures that the netdev is properly accessible for cleanup in case of errors. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23206", "url": "https://ubuntu.com/security/CVE-2026-23206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zero The driver allocates arrays for ports, FDBs, and filter blocks using kcalloc() with ethsw->sw_attr.num_ifs as the element count. When the device reports zero interfaces (either due to hardware configuration or firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10) instead of NULL. Later in dpaa2_switch_probe(), the NAPI initialization unconditionally accesses ethsw->ports[0]->netdev, which attempts to dereference ZERO_SIZE_PTR (address 0x10), resulting in a kernel panic. Add a check to ensure num_ifs is greater than zero after retrieving device attributes. This prevents the zero-sized allocations and subsequent invalid pointer dereference.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23204", "url": "https://ubuntu.com/security/CVE-2026-23204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: use skb_header_pointer_careful() skb_header_pointer() does not fully validate negative @offset values. Use skb_header_pointer_careful() instead. GangMin Kim provided a report and a repro fooling u32_classify(): BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0 net/sched/cls_u32.c:221", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23205", "url": "https://ubuntu.com/security/CVE-2026-23205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: fix memory leak in smb2_open_file() Reproducer: 1. server: directories are exported read-only 2. client: mount -t cifs //${server_ip}/export /mnt 3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct 4. client: umount /mnt 5. client: sleep 1 6. client: modprobe -r cifs The error message is as follows: ============================================================================= BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown() ----------------------------------------------------------------------------- Object 0x00000000d47521be @offset=14336 ... WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577 ... Call Trace: kmem_cache_destroy+0x94/0x190 cifs_destroy_request_bufs+0x3e/0x50 [cifs] cleanup_module+0x4e/0x540 [cifs] __se_sys_delete_module+0x278/0x400 __x64_sys_delete_module+0x5f/0x70 x64_sys_call+0x2299/0x2ff0 do_syscall_64+0x89/0x350 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs] WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23176", "url": "https://ubuntu.com/security/CVE-2026-23176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: toshiba_haps: Fix memory leaks in add/remove routines toshiba_haps_add() leaks the haps object allocated by it if it returns an error after allocating that object successfully. toshiba_haps_remove() does not free the object pointed to by toshiba_haps before clearing that pointer, so it becomes unreachable allocated memory. Address these memory leaks by using devm_kzalloc() for allocating the memory in question.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23216", "url": "https://ubuntu.com/security/CVE-2026-23216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count() In iscsit_dec_conn_usage_count(), the function calls complete() while holding the conn->conn_usage_lock. As soon as complete() is invoked, the waiter (such as iscsit_close_connection()) may wake up and proceed to free the iscsit_conn structure. If the waiter frees the memory before the current thread reaches spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function attempts to release a lock within the already-freed connection structure. Fix this by releasing the spinlock before calling complete().", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2026-23193", "url": "https://ubuntu.com/security/CVE-2026-23193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count() In iscsit_dec_session_usage_count(), the function calls complete() while holding the sess->session_usage_lock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsit_session structure immediately. This creates a race condition where the current thread may attempt to execute spin_unlock_bh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free. To resolve this, release the session_usage_lock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23260", "url": "https://ubuntu.com/security/CVE-2026-23260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: maple: free entry on mas_store_gfp() failure regcache_maple_write() allocates a new block ('entry') to merge adjacent ranges and then stores it with mas_store_gfp(). When mas_store_gfp() fails, the new 'entry' remains allocated and is never freed, leaking memory. Free 'entry' on the failure path; on success continue freeing the replaced neighbor blocks ('lower', 'upper').", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23179", "url": "https://ubuntu.com/security/CVE-2026-23179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready() When the socket is closed while in TCP_LISTEN a callback is run to flush all outstanding packets, which in turns calls nvmet_tcp_listen_data_ready() with the sk_callback_lock held. So we need to check if we are in TCP_LISTEN before attempting to get the sk_callback_lock() to avoid a deadlock.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23261", "url": "https://ubuntu.com/security/CVE-2026-23261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-fc: release admin tagset if init fails nvme_fabrics creates an NVMe/FC controller in following path: nvmf_dev_write() -> nvmf_create_ctrl() -> nvme_fc_create_ctrl() -> nvme_fc_init_ctrl() nvme_fc_init_ctrl() allocates the admin blk-mq resources right after nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the fail_ctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc. Check ctrl->ctrl.admin_tagset in the fail_ctrl path and call nvme_remove_admin_tag_set() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23178", "url": "https://ubuntu.com/security/CVE-2026-23178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report() `i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of data into `ihid->rawbuf`. The former can come from the userspace in the hidraw driver and is only bounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set `max_buffer_size` field of `struct hid_ll_driver` which we do not). The latter has size determined at runtime by the maximum size of different report types you could receive on any particular device and can be a much smaller value. Fix this by truncating `recv_len` to `ihid->bufsize - sizeof(__le16)`. The impact is low since access to hidraw devices requires root.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71268", "url": "https://ubuntu.com/security/CVE-2025-71268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix reservation leak in some error paths when inserting inline extent If we fail to allocate a path or join a transaction, we return from __cow_file_range_inline() without freeing the reserved qgroup data, resulting in a leak. Fix this by ensuring we call btrfs_qgroup_free_data() in such cases.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71270", "url": "https://ubuntu.com/security/CVE-2025-71270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: Enable exception fixup for specific ADE subcode This patch allows the LoongArch BPF JIT to handle recoverable memory access errors generated by BPF_PROBE_MEM* instructions. When a BPF program performs memory access operations, the instructions it executes may trigger ADEM exceptions. The kernel’s built-in BPF exception table mechanism (EX_TYPE_BPF) will generate corresponding exception fixup entries in the JIT compilation phase; however, the architecture-specific trap handling function needs to proactively call the common fixup routine to achieve exception recovery. do_ade(): fix EX_TYPE_BPF memory access exceptions for BPF programs, ensure safe execution. Relevant test cases: illegal address access tests in module_attach and subprogs_extable of selftests/bpf.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-71220", "url": "https://ubuntu.com/security/CVE-2025-71220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/server: call ksmbd_session_rpc_close() on error path in create_smb2_pipe() When ksmbd_iov_pin_rsp() fails, we should call ksmbd_session_rpc_close().", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71222", "url": "https://ubuntu.com/security/CVE-2025-71222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: ensure skb headroom before skb_push This avoids occasional skb_under_panic Oops from wl1271_tx_work. In this case, headroom is less than needed (typically 110 - 94 = 16 bytes).", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2025-71224", "url": "https://ubuntu.com/security/CVE-2025-71224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: ocb: skip rx_no_sta when interface is not joined ieee80211_ocb_rx_no_sta() assumes a valid channel context, which is only present after JOIN_OCB. RX may run before JOIN_OCB is executed, in which case the OCB interface is not operational. Skip RX peer handling when the interface is not joined to avoid warnings in the RX path.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23262", "url": "https://ubuntu.com/security/CVE-2026-23262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: Fix stats report corruption on queue count change The driver and the NIC share a region in memory for stats reporting. The NIC calculates its offset into this region based on the total size of the stats region and the size of the NIC's stats. When the number of queues is changed, the driver's stats region is resized. If the queue count is increased, the NIC can write past the end of the allocated stats region, causing memory corruption. If the queue count is decreased, there is a gap between the driver and NIC stats, leading to incorrect stats reporting. This change fixes the issue by allocating stats region with maximum size, and the offset calculation for NIC stats is changed to match with the calculation of the NIC.", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2025-38201", "url": "https://ubuntu.com/security/CVE-2025-38201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. Similar to: b541ba7d1f5a (\"netfilter: conntrack: clamp maximum hashtable size to INT_MAX\")", "cve_priority": "medium", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2026-23198", "url": "https://ubuntu.com/security/CVE-2026-23198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Don't clobber irqfd routing type when deassigning irqfd When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone. As a bonus, checking that the irqfd is active provides a convenient location for documenting _why_ KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens *before* the eventfd is detached), it will no longer receive updates via kvm_irq_routing_update(), and so KVM could deliver an event using stale routing information (relative to KVM_SET_GSI_ROUTING returning to userspace). As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information. As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd. Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irq_bypass_data being NULL when read by avic_update_iommu_vcpu_affinity(): BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Call Trace: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ end trace 0000000000000000 ]--- If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment. list_add corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:__list_add_valid_or_report+0x97/0xc0 Call Trace: avic_pi_update_irte+0x28e/0x2b0 [kvm_amd] kvm_pi_update_irte+0xbf/0x190 [kvm] kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm] irq_bypass_register_consumer+0xcd/0x170 [irqbypa ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23264", "url": "https://ubuntu.com/security/CVE-2026-23264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"drm/amd: Check if ASPM is enabled from PCIe subsystem\" This reverts commit 7294863a6f01248d72b61d38478978d638641bee. This commit was erroneously applied again after commit 0ab5d711ec74 (\"drm/amd: Refactor `amdgpu_aspm` to be evaluated per device\") removed it, leading to very hard to debug crashes, when used with a system with two AMD GPUs of which only one supports ASPM. (cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080)", "cve_priority": "medium", "cve_public_date": "2026-03-18 18:16:00 UTC" }, { "cve": "CVE-2026-23187", "url": "https://ubuntu.com/security/CVE-2026-23187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domains Fix out-of-range access of bc->domains in imx8m_blk_ctrl_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23148", "url": "https://ubuntu.com/security/CVE-2026-23148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference There is a race condition in nvmet_bio_done() that can cause a NULL pointer dereference in blk_cgroup_bio_start(): 1. nvmet_bio_done() is called when a bio completes 2. nvmet_req_complete() is called, which invokes req->ops->queue_response(req) 3. The queue_response callback can re-queue and re-submit the same request 4. The re-submission reuses the same inline_bio from nvmet_req 5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete) invokes bio_uninit() for inline_bio, which sets bio->bi_blkg to NULL 6. The re-submitted bio enters submit_bio_noacct_nocheck() 7. blk_cgroup_bio_start() dereferences bio->bi_blkg, causing a crash: BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blk_cgroup_bio_start+0x10/0xd0 Call Trace: submit_bio_noacct_nocheck+0x44/0x250 nvmet_bdev_execute_rw+0x254/0x370 [nvmet] process_one_work+0x193/0x3c0 worker_thread+0x281/0x3a0 Fix this by reordering nvmet_bio_done() to call nvmet_req_bio_put() BEFORE nvmet_req_complete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23166", "url": "https://ubuntu.com/security/CVE-2026-23166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues Add NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashes during resume from suspend when rings[q_idx]->q_vector is NULL. Tested adaptor: 60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02) Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003] SR-IOV state: both disabled and enabled can reproduce this issue. kernel version: v6.18 Reproduce steps: Boot up and execute suspend like systemctl suspend or rtcwake. Log: <1>[ 231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040 <1>[ 231.444052] #PF: supervisor read access in kernel mode <1>[ 231.444484] #PF: error_code(0x0000) - not-present page <6>[ 231.444913] PGD 0 P4D 0 <4>[ 231.445342] Oops: Oops: 0000 [#1] SMP NOPTI <4>[ 231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170 <4>[ 231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89 <4>[ 231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202 <4>[ 231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010 <4>[ 231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000 <4>[ 231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000 <4>[ 231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 <4>[ 231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000 <4>[ 231.450265] FS: 00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000 <4>[ 231.450715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0 <4>[ 231.451629] PKRU: 55555554 <4>[ 231.452076] Call Trace: <4>[ 231.452549] <4>[ 231.452996] ? ice_vsi_set_napi_queues+0x4d/0x110 [ice] <4>[ 231.453482] ice_resume+0xfd/0x220 [ice] <4>[ 231.453977] ? __pfx_pci_pm_resume+0x10/0x10 <4>[ 231.454425] pci_pm_resume+0x8c/0x140 <4>[ 231.454872] ? __pfx_pci_pm_resume+0x10/0x10 <4>[ 231.455347] dpm_run_callback+0x5f/0x160 <4>[ 231.455796] ? dpm_wait_for_superior+0x107/0x170 <4>[ 231.456244] device_resume+0x177/0x270 <4>[ 231.456708] dpm_resume+0x209/0x2f0 <4>[ 231.457151] dpm_resume_end+0x15/0x30 <4>[ 231.457596] suspend_devices_and_enter+0x1da/0x2b0 <4>[ 231.458054] enter_state+0x10e/0x570 Add defensive checks for both the ring pointer and its q_vector before dereferencing, allowing the system to resume successfully even when q_vectors are unmapped.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23151", "url": "https://ubuntu.com/security/CVE-2026-23151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix memory leak in set_ssp_complete Fix memory leak in set_ssp_complete() where mgmt_pending_cmd structures are not freed after being removed from the pending list. Commit 302a1f674c00 (\"Bluetooth: MGMT: Fix possible UAFs\") replaced mgmt_pending_foreach() calls with individual command handling but missed adding mgmt_pending_free() calls in both error and success paths of set_ssp_complete(). Other completion functions like set_le_complete() were fixed correctly in the same commit. This causes a memory leak of the mgmt_pending_cmd structure and its associated parameter data for each SSP command that completes. Add the missing mgmt_pending_free(cmd) calls in both code paths to fix the memory leak. Also fix the same issue in set_advertising_complete().", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23163", "url": "https://ubuntu.com/security/CVE-2026-23163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and ih2 interrupt ring buffers are not initialized. This is by design, as these secondary IH rings are only available on discrete GPUs. See vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when AMD_IS_APU is set. However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to get the timestamp of the last interrupt entry. When retry faults are enabled on APUs (noretry=0), this function is called from the SVM page fault recovery path, resulting in a NULL pointer dereference when amdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[]. The crash manifests as: BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu] Call Trace: amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu] svm_range_restore_pages+0xae5/0x11c0 [amdgpu] amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu] gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu] amdgpu_ih_process+0x84/0x100 [amdgpu] This issue was exposed by commit 1446226d32a4 (\"drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1\") which changed the default for Renoir APU from noretry=1 to noretry=0, enabling retry fault handling and thus exercising the buggy code path. Fix this by adding a check for ih1.ring_size before attempting to use it. Also restore the soft_ih support from commit dd299441654f (\"drm/amdgpu: Rework retry fault removal\"). This is needed if the hardware doesn't support secondary HW IH rings. v2: additional updates (Alex) (cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23159", "url": "https://ubuntu.com/security/CVE-2026-23159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf: sched: Fix perf crash with new is_user_task() helper In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the task_struct mm field. If it was non NULL, it was a user task and if not it was a kernel task. But things have changed over time, and some kernel tasks now have their own mm field. An idea was made to instead test PF_KTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PF_KTHREAD directly. It was later found that not all kernel threads set PF_KTHREAD. The io-uring helpers instead set PF_USER_WORKER and this needed to be added as well. But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference. Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field. Instead of making this modification in every location, create a new is_user_task() helper function that does all the tests needed to know if it is safe to read the user space memory or not. [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2024-58096", "url": "https://ubuntu.com/security/CVE-2024-58096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode ath11k_hal_srng_* should be used with srng->lock to protect srng data. For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock. So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319 So add srng->lock for them to avoid such warnings. Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx(). Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-40039", "url": "https://ubuntu.com/security/CVE-2025-40039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix race condition in RPC handle list access The 'sess->rpc_handle_list' XArray manages RPC handles within a ksmbd session. Access to this list is intended to be protected by 'sess->rpc_lock' (an rw_semaphore). However, the locking implementation was flawed, leading to potential race conditions. In ksmbd_session_rpc_open(), the code incorrectly acquired only a read lock before calling xa_store() and xa_erase(). Since these operations modify the XArray structure, a write lock is required to ensure exclusive access and prevent data corruption from concurrent modifications. Furthermore, ksmbd_session_rpc_method() accessed the list using xa_load() without holding any lock at all. This could lead to reading inconsistent data or a potential use-after-free if an entry is concurrently removed and the pointer is dereferenced. Fix these issues by: 1. Using down_write() and up_write() in ksmbd_session_rpc_open() to ensure exclusive access during XArray modification, and ensuring the lock is correctly released on error paths. 2. Adding down_read() and up_read() in ksmbd_session_rpc_method() to safely protect the lookup.", "cve_priority": "medium", "cve_public_date": "2025-10-28 12:15:00 UTC" }, { "cve": "CVE-2026-23093", "url": "https://ubuntu.com/security/CVE-2026-23093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbd: fix dma_unmap_sg() nents The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23102", "url": "https://ubuntu.com/security/CVE-2026-23102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Fix restoration of SVE context When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL. (1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time. (2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length. Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear. For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23170", "url": "https://ubuntu.com/security/CVE-2026-23170", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imx/tve: fix probe device leak Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23168", "url": "https://ubuntu.com/security/CVE-2026-23168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: flex_proportions: make fprop_new_period() hardirq safe Bernd has reported a lockdep splat from flexible proportions code that is essentially complaining about the following race: run_timer_softirq - we are in softirq context call_timer_fn writeout_period fprop_new_period write_seqcount_begin(&p->sequence); ... blk_mq_end_request() \t blk_update_request() \t ext4_end_bio() \t folio_end_writeback() \t\t__wb_writeout_add() \t\t __fprop_add_percpu_max() \t\t if (unlikely(max_frac < FPROP_FRAC_BASE)) { \t\t fprop_fraction_percpu() \t\t\tseq = read_seqcount_begin(&p->sequence); \t\t\t - sees odd sequence so loops indefinitely Note that a deadlock like this is only possible if the bdi has configured maximum fraction of writeout throughput which is very rare in general but frequent for example for FUSE bdis. To fix this problem we have to make sure write section of the sequence counter is irqsafe.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23156", "url": "https://ubuntu.com/security/CVE-2026-23156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efivarfs: fix error propagation in efivar_entry_get() efivar_entry_get() always returns success even if the underlying __efivar_entry_get() fails, masking errors. This may result in uninitialized heap memory being copied to userspace in the efivarfs_file_read() path. Fix it by returning the error from __efivar_entry_get().", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23167", "url": "https://ubuntu.com/security/CVE-2026-23167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix race between rfkill and nci_unregister_device(). syzbot reported the splat below [0] without a repro. It indicates that struct nci_dev.cmd_wq had been destroyed before nci_close_device() was called via rfkill. nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which (I think) was called from virtual_ncidev_close() when syzbot close()d an fd of virtual_ncidev. The problem is that nci_unregister_device() destroys nci_dev.cmd_wq first and then calls nfc_unregister_device(), which removes the device from rfkill by rfkill_unregister(). So, the device is still visible via rfkill even after nci_dev.cmd_wq is destroyed. Let's unregister the device from rfkill first in nci_unregister_device(). Note that we cannot call nfc_unregister_device() before nci_close_device() because 1) nfc_unregister_device() calls device_del() which frees all memory allocated by devm_kzalloc() and linked to ndev->conn_info_list 2) nci_rx_work() could try to queue nci_conn_info to ndev->conn_info_list which could be leaked Thus, nfc_unregister_device() is split into two functions so we can remove rfkill interfaces only before nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Modules linked in: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Call Trace: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ksys_write+0x150/0x270 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa59b39acb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9 RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007 RBP: 00007fa59b408bf7 R08: ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23173", "url": "https://ubuntu.com/security/CVE-2026-23173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: TC, delete flows only for existing peers When deleting TC steering flows, iterate only over actual devcom peers instead of assuming all possible ports exist. This avoids touching non-existent peers and ensures cleanup is limited to devices the driver is currently connected to. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: mlx5e_tc_del_flow+0x46/0x270 [mlx5_core] mlx5e_flow_put+0x25/0x50 [mlx5_core] mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core] tc_setup_cb_reoffload+0x20/0x80 fl_reoffload+0x26f/0x2f0 [cls_flower] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core] tcf_block_playback_offloads+0x9e/0x1c0 tcf_block_unbind+0x7b/0xd0 tcf_block_setup+0x186/0x1d0 tcf_block_offload_cmd.isra.0+0xef/0x130 tcf_block_offload_unbind+0x43/0x70 __tcf_block_put+0x85/0x160 ingress_destroy+0x32/0x110 [sch_ingress] __qdisc_destroy+0x44/0x100 qdisc_graft+0x22b/0x610 tc_get_qdisc+0x183/0x4d0 rtnetlink_rcv_msg+0x2d7/0x3d0 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x249/0x320 ? __alloc_skb+0x102/0x1f0 netlink_sendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1ef/0x230 ? copy_msghdr_from_user+0x6c/0xa0 ___sys_sendmsg+0x7f/0xc0 ? ___sys_recvmsg+0x8a/0xc0 ? __sys_sendto+0x119/0x180 __sys_sendmsg+0x61/0xb0 do_syscall_64+0x55/0x640 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764 RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23150", "url": "https://ubuntu.com/security/CVE-2026-23150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame(). syzbot reported various memory leaks related to NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] The leading log hinted that nfc_llcp_send_ui_frame() failed to allocate skb due to sock_error(sk) being -ENXIO. ENXIO is set by nfc_llcp_socket_release() when struct nfc_llcp_local is destroyed by local_cleanup(). The problem is that there is no synchronisation between nfc_llcp_send_ui_frame() and local_cleanup(), and skb could be put into local->tx_queue after it was purged in local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() is called for struct nfc_llcp_local only after nfc_llcp_remove_local() unlinks it from llcp_devices. If we hold local->tx_queue.lock then, we can synchronise the thread and nfc_llcp_send_ui_frame(). Let's do that and check list_empty(&local->list) before queuing skb to local->tx_queue in nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm \"syz.0.17\", pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm \"syz.0.17\", pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23164", "url": "https://ubuntu.com/security/CVE-2026-23164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rocker: fix memory leak in rocker_world_port_post_fini() In rocker_world_port_pre_init(), rocker_port->wpriv is allocated with kzalloc(wops->port_priv_size, GFP_KERNEL). However, in rocker_world_port_post_fini(), the memory is only freed when wops->port_post_fini callback is set: if (!wops->port_post_fini) return; wops->port_post_fini(rocker_port); kfree(rocker_port->wpriv); Since rocker_ofdpa_ops does not implement port_post_fini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpa_port) bytes per port on every device removal. Fix this by always calling kfree(rocker_port->wpriv) regardless of whether the port_post_fini callback exists.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23172", "url": "https://ubuntu.com/security/CVE-2026-23172", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: fix potential skb->frags overflow in RX path When receiving data in the DPMAIF RX path, the t7xx_dpmaif_set_frag_to_skb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow in skb_shinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior. This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf (\"mt76: fix array overflow on receiving too many fragments for a packet\"). The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects. Fix this by adding a bounds check before calling skb_add_rx_frag() to ensure nr_frags does not exceed MAX_SKB_FRAGS. The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23212", "url": "https://ubuntu.com/security/CVE-2026-23212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: annotate data-races around slave->last_rx slave->last_rx and slave->target_last_arp_rx[...] can be read and written locklessly. Add READ_ONCE() and WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 ... write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335 bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533 __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039 __netif_receive_skb_one_core net/core/dev.c:6150 [inline] __netif_receive_skb+0x59/0x270 net/core/dev.c:6265 netif_receive_skb_internal net/core/dev.c:6351 [inline] netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410 br_netif_receive_skb net/bridge/br_input.c:30 [inline] NF_HOOK include/linux/netfilter.h:318 [inline] ... value changed: 0x0000000100005365 -> 0x0000000100005366", "cve_priority": "medium", "cve_public_date": "2026-02-18 15:18:00 UTC" }, { "cve": "CVE-2026-23160", "url": "https://ubuntu.com/security/CVE-2026-23160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeon_ep: Fix memory leak in octep_device_setup() In octep_device_setup(), if octep_ctrl_net_init() fails, the function returns directly without unmapping the mapped resources and freeing the allocated configuration memory. Fix this by jumping to the unsupported_dev label, which performs the necessary cleanup. This aligns with the error handling logic of other paths in this function. Compile tested only. Issue found using a prototype static analysis tool and code review.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23146", "url": "https://ubuntu.com/security/CVE-2026-23146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling hci_uart_register_dev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hci_uart_tx_wakeup() may schedule write_work before hu->priv is initialized, leading to a NULL pointer dereference in hci_uart_write_work() when proto->dequeue() accesses hu->priv. The race condition is: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() tty write wakeup hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // initializes hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accesses hu->priv (NULL!) Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23394", "url": "https://ubuntu.com/security/CVE-2026-23394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2025-38591", "url": "https://ubuntu.com/security/CVE-2025-38591", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject narrower access to pointer ctx fields The following BPF program, simplified from a syzkaller repro, causes a kernel warning: r0 = *(u8 *)(r1 + 169); exit; With pointer field sk being at offset 168 in __sk_buff. This access is detected as a narrower read in bpf_skb_is_valid_access because it doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed and later proceeds to bpf_convert_ctx_access. Note that for the \"is_narrower_load\" case in the convert_ctx_accesses(), the insn->off is aligned, so the cnt may not be 0 because it matches the offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However, the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1) This patch fixes that to return a proper \"invalid bpf_context access off=X size=Y\" error on the load instruction. The same issue affects multiple other fields in context structures that allow narrow access. Some other non-affected fields (for sk_msg, sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for consistency. Note this syzkaller crash was reported in the \"Closes\" link below, which used to be about a different bug, fixed in commit fce7bd8e385a (\"bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()\"). Because syzbot somehow confused the two bugs, the new crash and repro didn't get reported to the mailing list.", "cve_priority": "medium", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2026-23035", "url": "https://ubuntu.com/security/CVE-2026-23035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails. Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a valid netdev. On mlx5e_remove: Check validity of priv->profile, before attempting to cleanup any resources that might be not there. This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure. $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 $ devlink dev reload pci/0000:00:03.0 ==> oops BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0 RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10 R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0 R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400 FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0 Call Trace: mlx5e_remove+0x57/0x110 device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-22996", "url": "https://ubuntu.com/security/CVE-2026-22996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5e_dev and get mdev from the containing mlx5_adev aux device structure. This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure. $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 $ devlink dev reload pci/0000:00:03.0 ==> oops BUG: kernel NULL pointer dereference, address: 0000000000000520 #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: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_remove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS: 00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace: device_release_driver_internal+0x19c/0x200 bus_remove_device+0xc6/0x130 device_del+0x160/0x3d0 ? devl_param_driverinit_value_get+0x2d/0x90 mlx5_detach_device+0x89/0xe0 mlx5_unload_one_devl_locked+0x3a/0x70 mlx5_devlink_reload_down+0xc8/0x220 devlink_reload+0x7d/0x260 devlink_nl_reload_doit+0x45b/0x5a0 genl_family_rcv_msg_doit+0xe8/0x140", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23000", "url": "https://ubuntu.com/security/CVE-2026-23000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash on profile change rollback failure mlx5e_netdev_change_profile can fail to attach a new profile and can fail to rollback to old profile, in such case, we could end up with a dangling netdev with a fully reset netdev_priv. A retry to change profile, e.g. another attempt to call mlx5e_netdev_change_profile via switchdev mode change, will crash trying to access the now NULL priv->mdev. This fix allows mlx5e_netdev_change_profile() to handle previous failures and an empty priv, by not assuming priv is valid. Pass netdev and mdev to all flows requiring mlx5e_netdev_change_profile() and avoid passing priv. In mlx5e_netdev_change_profile() check if current priv is valid, and if not, just attach the new profile without trying to access the old one. This fixes the following oops, when enabling switchdev mode for the 2nd time after first time failure: ## Enabling switchdev mode first time: mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 ^^^^^^^^ mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) ## retry: Enabling switchdev mode 2nd time: mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload BUG: kernel NULL pointer dereference, address: 0000000000000038 #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: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_detach_netdev+0x3c/0x90 Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS: 00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Call Trace: mlx5e_netdev_change_profile+0x45/0xb0 mlx5e_vport_rep_load+0x27b/0x2d0 mlx5_esw_offloads_rep_load+0x72/0xf0 esw_offloads_enable+0x5d0/0x970 mlx5_eswitch_enable_locked+0x349/0x430 ? is_mp_supported+0x57/0xb0 mlx5_devlink_eswitch_mode_set+0x26b/0x430 devlink_nl_eswitch_set_doit+0x6f/0xf0 genl_family_rcv_msg_doit+0xe8/0x140 genl_rcv_msg+0x18b/0x290 ? __pfx_devlink_nl_pre_doit+0x10/0x10 ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10 ? __pfx_devlink_nl_post_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x52/0x100 genl_rcv+0x28/0x40 netlink_unicast+0x282/0x3e0 ? __alloc_skb+0xd6/0x190 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x213/0x220 ? __sys_recvmsg+0x6a/0xd0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdfb8495047", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23053", "url": "https://ubuntu.com/security/CVE-2026-23053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a deadlock involving nfs_release_folio() Wang Zhaolong reports a deadlock involving NFSv4.1 state recovery waiting on kthreadd, which is attempting to reclaim memory by calling nfs_release_folio(). The latter cannot make progress due to state recovery being needed. It seems that the only safe thing to do here is to kick off a writeback of the folio, without waiting for completion, or else kicking off an asynchronous commit.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23050", "url": "https://ubuntu.com/security/CVE-2026-23050", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix a deadlock when returning a delegation during open() Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935 The issue is that the delegreturn is being asked to wait for a layout return that cannot complete because a state recovery was initiated. The state recovery cannot complete until the open() finishes processing the delegations it was given. The solution is to propagate the existing flags that indicate a non-blocking call to the function pnfs_roc(), so that it knows not to wait in this situation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23005", "url": "https://ubuntu.com/security/CVE-2026-23005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1 When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel. E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's call to fpu_update_guest_xfd(). and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ---[ end trace 0000000000000000 ]--- The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component): If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i). Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD. Therefore, XFD can only go out of sync with XSTATE_BV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features. [Move clea ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2024-58097", "url": "https://ubuntu.com/security/CVE-2024-58097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix RCU stall while reaping monitor destination ring While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id. However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash. kernel log: ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2025-68365", "url": "https://ubuntu.com/security/CVE-2025-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Initialize allocated memory before use KMSAN reports: Multiple uninitialized values detected: - KMSAN: uninit-value in ntfs_read_hdr (3) - KMSAN: uninit-value in bcmp (3) Memory is allocated by __getname(), which is a wrapper for kmem_cache_alloc(). This memory is used before being properly cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to properly allocate and clear memory before use.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2025-37926", "url": "https://ubuntu.com/security/CVE-2025-37926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_session_rpc_open A UAF issue can occur due to a race condition between ksmbd_session_rpc_open() and __session_rpc_close(). Add rpc_lock to the session to protect it.", "cve_priority": "medium", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-23030", "url": "https://ubuntu.com/security/CVE-2026-23030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe() The for_each_available_child_of_node() calls of_node_put() to release child_np in each success loop. After breaking from the loop with the child_np has been released, the code will jump to the put_child label and will call the of_node_put() again if the devm_request_threaded_irq() fails. These cause a double free bug. Fix by returning directly to avoid the duplicate of_node_put().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23025", "url": "https://ubuntu.com/security/CVE-2026-23025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: prevent pcp corruption with SMP=n The kernel test robot has reported: BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: __dump_stack (lib/dump_stack.c:95) dump_stack_lvl (lib/dump_stack.c:123) dump_stack (lib/dump_stack.c:130) spin_dump (kernel/locking/spinlock_debug.c:71) do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?) _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138) __free_frozen_pages (mm/page_alloc.c:2973) ___free_pages (mm/page_alloc.c:5295) __free_pages (mm/page_alloc.c:5334) tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290) ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289) ? rcu_core (kernel/rcu/tree.c:?) rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcu_core_si (kernel/rcu/tree.c:2879) handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725) irq_exit_rcu (kernel/softirq.c:741) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052) RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194) free_pcppages_bulk (mm/page_alloc.c:1494) drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632) __drain_all_pages (mm/page_alloc.c:2731) drain_all_pages (mm/page_alloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork (arch/x86/kernel/process.c:164) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) Matthew has analyzed the report and identified that in drain_page_zone() we are in a section protected by spin_lock(&pcp->lock) and then get an interrupt that attempts spin_trylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spin_trylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure. The problem has been introduced by commit 574907741599 (\"mm/page_alloc: leave IRQs enabled for per-cpu page allocations\"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spin_trylock() sections on SMP=n, but the need to prevent the nesting in spin_lock() has not been recognized. Fix it by introducing local wrappers that change the spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places that do spin_lock(&pcp->lock). [vbabka@suse.cz: add pcp_ prefix to the spin_lock_irqsave wrappers, per Steven]", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71186", "url": "https://ubuntu.com/security/CVE-2025-71186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: stm32: dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23078", "url": "https://ubuntu.com/security/CVE-2026-23078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23142", "url": "https://ubuntu.com/security/CVE-2026-23142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure When a DAMOS-scheme DAMON sysfs directory setup fails after setup of access_pattern/ directory, subdirectories of access_pattern/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked. Cleanup the directories under such failures.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23075", "url": "https://ubuntu.com/security/CVE-2026-23075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In esd_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback esd_usb_read_bulk_callback(), the URBs are processed and resubmitted. In esd_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esd_usb_close(). Fix the memory leak by anchoring the URB in the esd_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-68725", "url": "https://ubuntu.com/security/CVE-2025-68725", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d (\"gso: validate gso_type in GSO handlers\") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there.", "cve_priority": "medium", "cve_public_date": "2025-12-24 11:16:00 UTC" }, { "cve": "CVE-2026-23097", "url": "https://ubuntu.com/security/CVE-2026-23097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: migrate: correct lock ordering for hugetlb file folios Syzbot has found a deadlock (analyzed by Lance Yang): 1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock). 2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire folio_lock. migrate_pages() -> migrate_hugetlbs() -> unmap_and_move_huge_page() <- Takes folio_lock! -> remove_migration_ptes() -> __rmap_walk_file() -> i_mmap_lock_read() <- Waits for i_mmap_rwsem(read lock)! hugetlbfs_fallocate() -> hugetlbfs_punch_hole() <- Takes i_mmap_rwsem(write lock)! -> hugetlbfs_zero_partial_page() -> filemap_lock_hugetlb_folio() -> filemap_lock_folio() -> __filemap_get_folio <- Waits for folio_lock! The migration path is the one taking locks in the wrong order according to the documentation at the top of mm/rmap.c. So expand the scope of the existing i_mmap_lock to cover the calls to remove_migration_ptes() too. This is (mostly) how it used to be after commit c0d0381ade79. That was removed by 336bf30eb765 for both file & anon hugetlb pages when it should only have been removed for anon hugetlb pages.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23108", "url": "https://ubuntu.com/security/CVE-2026-23108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23080", "url": "https://ubuntu.com/security/CVE-2026-23080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback mcba_usb_read_bulk_callback(), the URBs are processed and resubmitted. In mcba_usb_close() -> mcba_urb_unlink() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the mcba_usb_read_bulk_callback()to the priv->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23061", "url": "https://ubuntu.com/security/CVE-2026-23061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23058", "url": "https://ubuntu.com/security/CVE-2026-23058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak\"). In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close(). Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23085", "url": "https://ubuntu.com/security/CVE-2026-23085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the qemu virt model to crash in the GICv3 driver, which allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses for ZONE_NORMAL, and the ITS driver stores the physical address in a 32-bit 'unsigned long' variable. Change the itt_addr variable to the correct phys_addr_t type instead, along with all other variables in this driver that hold a physical address. The gicv5 driver correctly uses u64 variables, while all other irqchip drivers don't call virt_to_phys or similar interfaces. It's expected that other device drivers have similar issues, but fixing this one is sufficient for booting a virtio based guest.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23116", "url": "https://ubuntu.com/security/CVE-2026-23116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu For i.MX8MQ platform, the ADB in the VPUMIX domain has no separate reset and clock enable bits, but is ungated and reset together with the VPUs. So we can't reset G1 or G2 separately, it may led to the system hang. Remove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data. Let imx8mq_vpu_power_notifier() do really vpu reset.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23098", "url": "https://ubuntu.com/security/CVE-2026-23098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netrom: fix double-free in nr_route_frame() In nr_route_frame(), old_skb is immediately freed without checking if nr_neigh->ax25 pointer is NULL. Therefore, if nr_neigh->ax25 is NULL, the caller function will free old_skb again, causing a double-free bug. Therefore, to prevent this, we need to modify it to check whether nr_neigh->ax25 is NULL before freeing old_skb.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23063", "url": "https://ubuntu.com/security/CVE-2026-23063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: ensure safe queue release with state management Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23056", "url": "https://ubuntu.com/security/CVE-2026-23056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: implement mremap in uacce_vm_ops to return -EPERM The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23094", "url": "https://ubuntu.com/security/CVE-2026-23094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix isolate sysfs check condition uacce supports the device isolation feature. If the driver implements the isolate_err_threshold_read and isolate_err_threshold_write callback functions, uacce will create sysfs files now. Users can read and configure the isolation policy through sysfs. Currently, sysfs files are created as long as either isolate_err_threshold_read or isolate_err_threshold_write callback functions are present. However, accessing a non-existent callback function may cause the system to crash. Therefore, intercept the creation of sysfs if neither read nor write exists; create sysfs if either is supported, but intercept unsupported operations at the call site.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23096", "url": "https://ubuntu.com/security/CVE-2026-23096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23091", "url": "https://ubuntu.com/security/CVE-2026-23091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23088", "url": "https://ubuntu.com/security/CVE-2026-23088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix crash on synthetic stacktrace field usage When creating a synthetic event based on an existing synthetic event that had a stacktrace field and the new synthetic event used that field a kernel crash occurred: ~# cd /sys/kernel/tracing ~# echo 's:stack unsigned long stack[];' > dynamic_events ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/trigger The above creates a synthetic event that takes a stacktrace when a task schedules out in a non-running state and passes that stacktrace to the sched_switch event when that task schedules back in. It triggers the \"stack\" synthetic event that has a stacktrace as its field (called \"stack\"). ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/trigger The above makes another synthetic event called \"syscall_stack\" that attaches the first synthetic event (stack) to the sys_exit trace event and records the stacktrace from the stack event with the id of the system call that is exiting. When enabling this event (or using it in a historgram): ~# echo 1 > events/synthetic/syscall_stack/enable Produces a kernel crash! BUG: unable to handle page fault for address: 0000000000400010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 Call Trace: ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpstate+0x3e/0x90 ? _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 ? __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reason is that the stacktrace field is not labeled as such, and is treated as a normal field and not as a dynamic event that it is. In trace_event_raw_event_synth() the event is field is still treated as a dynamic array, but the retrieval of the data is considered a normal field, and the reference is just the meta data: // Meta data is retrieved instead of a dynamic array ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23090", "url": "https://ubuntu.com/security/CVE-2026-23090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: core: fix device reference leak on report present Slimbus devices can be allocated dynamically upon reception of report-present messages. Make sure to drop the reference taken when looking up already registered devices. Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23128", "url": "https://ubuntu.com/security/CVE-2026-23128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: Set __nocfi on swsusp_arch_resume() A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusp_arch_suspend_exit() is marked with SYM_CODE_*() and does not have a CFI hash, but swsusp_arch_resume() will attempt to verify the CFI hash when calling a copy of swsusp_arch_suspend_exit(). Given that there's an existing requirement that the entrypoint to swsusp_arch_suspend_exit() is the first byte of the .hibernate_exit.text section, we cannot fix this by marking swsusp_arch_suspend_exit() with SYM_FUNC_*(). The simplest fix for now is to disable the CFI check in swsusp_arch_resume(). Mark swsusp_arch_resume() as __nocfi to disable the CFI check. [1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but active_mm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusp_arch_resume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusp_arch_resume+0x2ac/0x344 [ 22.991934][ T1] hibernation_restore+0x158/0x18c [ 22.991934][ T1] load_image_and_restore+0xb0/0xec [ 22.991934][ T1] software_resume+0xf4/0x19c [ 22.991934][ T1] software_resume_initcall+0x34/0x78 [ 22.991934][ T1] do_one_initcall+0xe8/0x370 [ 22.991934][ T1] do_initcall_level+0xc8/0x19c [ 22.991934][ T1] do_initcalls+0x70/0xc0 [ 22.991934][ T1] do_basic_setup+0x1c/0x28 [ 22.991934][ T1] kernel_init_freeable+0xe0/0x148 [ 22.991934][ T1] kernel_init+0x20/0x1a8 [ 22.991934][ T1] ret_from_fork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110) [catalin.marinas@arm.com: commit log updated by Mark Rutland]", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23107", "url": "https://ubuntu.com/security/CVE-2026-23107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA The code to restore a ZA context doesn't attempt to allocate the task's sve_state before setting TIF_SME. Consequently, restoring a ZA context can place a task into an invalid state where TIF_SME is set but the task's sve_state is NULL. In legitimate but uncommon cases where the ZA signal context was NOT created by the kernel in the context of the same task (e.g. if the task is saved/restored with something like CRIU), we have no guarantee that sve_state had been allocated previously. In these cases, userspace can enter streaming mode without trapping while sve_state is NULL, causing a later NULL pointer dereference when the kernel attempts to store the register state: | # ./sigreturn-za | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000046 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x06: level 2 translation fault | Data abort info: | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00 | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000 | Internal error: Oops: 0000000096000046 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : sve_save_state+0x4/0xf0 | lr : fpsimd_save_user_state+0xb0/0x1c0 | sp : ffff80008070bcc0 | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000 | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020 | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0 | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440 | Call trace: | sve_save_state+0x4/0xf0 (P) | fpsimd_thread_switch+0x48/0x198 | __switch_to+0x20/0x1c0 | __schedule+0x36c/0xce0 | schedule+0x34/0x11c | exit_to_user_mode_loop+0x124/0x188 | el0_interrupt+0xc8/0xd8 | __el0_irq_handler_common+0x18/0x24 | el0t_64_irq_handler+0x10/0x1c | el0t_64_irq+0x198/0x19c | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ end trace 0000000000000000 ]--- Fix this by having restore_za_context() ensure that the task's sve_state is allocated, matching what we do when taking an SME trap. Any live SVE/SSVE state (which is restored earlier from a separate signal context) must be preserved, and hence this is not zeroed.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23073", "url": "https://ubuntu.com/security/CVE-2026-23073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rsi: Fix memory corruption due to not set vif driver data size The struct ieee80211_vif contains trailing space for vif driver data, when struct ieee80211_vif is allocated, the total memory size that is allocated is sizeof(struct ieee80211_vif) + size of vif driver data. The size of vif driver data is set by each WiFi driver as needed. The RSI911x driver does not set vif driver data size, no trailing space for vif driver data is therefore allocated past struct ieee80211_vif . The RSI911x driver does however use the vif driver data to store its vif driver data structure \"struct vif_priv\". An access to vif->drv_priv leads to access out of struct ieee80211_vif bounds and corruption of some memory. In case of the failure observed locally, rsi_mac80211_add_interface() would write struct vif_priv *vif_info = (struct vif_priv *)vif->drv_priv; vif_info->vap_id = vap_idx. This write corrupts struct fq_tin member struct list_head new_flows . The flow = list_first_entry(head, struct fq_flow, flowchain); in fq_tin_reset() then reports non-NULL bogus address, which when accessed causes a crash. The trigger is very simple, boot the machine with init=/bin/sh , mount devtmpfs, sysfs, procfs, and then do \"ip link set wlan0 up\", \"sleep 1\", \"ip link set wlan0 down\" and the crash occurs. Fix this by setting the correct size of vif driver data, which is the size of \"struct vif_priv\", so that memory is allocated and the driver can store its driver data in it, instead of corrupting memory around it.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23135", "url": "https://ubuntu.com/security/CVE-2026-23135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23133", "url": "https://ubuntu.com/security/CVE-2026-23133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: fix dma_free_coherent() pointer dma_alloc_coherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-71200", "url": "https://ubuntu.com/security/CVE-2025-71200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode When operating in HS200 or HS400 timing modes, reducing the clock frequency below 52MHz will lead to link broken as the Rockchip DWC MSHC controller requires maintaining a minimum clock of 52MHz in these modes. Add a check to prevent illegal clock reduction through debugfs: root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock root@debian:/# [ 30.090146] mmc0: running CQE recovery mmc0: cqhci: Failed to halt mmc0: cqhci: spurious TCN for tag 0 WARNING: drivers/mmc/host/cqhci-core.c:797 at cqhci_irq+0x254/0x818, CPU#1: kworker/1:0H/24 Modules linked in: CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) Workqueue: kblockd blk_mq_run_work_fn pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cqhci_irq+0x254/0x818 lr : cqhci_irq+0x254/0x818 ...", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23089", "url": "https://ubuntu.com/security/CVE-2026-23089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free() When snd_usb_create_mixer() fails, snd_usb_mixer_free() frees mixer->id_elems but the controls already added to the card still reference the freed memory. Later when snd_card_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read. Call trace: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Fix by calling snd_ctl_remove() for all mixer controls before freeing id_elems. We save the next pointer first because snd_ctl_remove() frees the current element.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23076", "url": "https://ubuntu.com/security/CVE-2026-23076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71199", "url": "https://ubuntu.com/security/CVE-2025-71199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23101", "url": "https://ubuntu.com/security/CVE-2026-23101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23064", "url": "https://ubuntu.com/security/CVE-2026-23064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: avoid possible NULL deref tcf_ife_encode() must make sure ife_encode() does not return NULL. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:ife_tlv_meta_encode+0x41/0xa0 net/ife/ife.c:166 CPU: 3 UID: 0 PID: 8990 Comm: syz.0.696 Not tainted syzkaller #0 PREEMPT(full) Call Trace: ife_encode_meta_u32+0x153/0x180 net/sched/act_ife.c:101 tcf_ife_encode net/sched/act_ife.c:841 [inline] tcf_ife_act+0x1022/0x1de0 net/sched/act_ife.c:877 tc_act include/net/tc_wrapper.h:130 [inline] tcf_action_exec+0x1c0/0xa20 net/sched/act_api.c:1152 tcf_exts_exec include/net/pkt_cls.h:349 [inline] mall_classify+0x1a0/0x2a0 net/sched/cls_matchall.c:42 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1764 [inline] tcf_classify+0x7f2/0x1380 net/sched/cls_api.c:1860 multiq_classify net/sched/sch_multiq.c:39 [inline] multiq_enqueue+0xe0/0x510 net/sched/sch_multiq.c:66 dev_qdisc_enqueue+0x45/0x250 net/core/dev.c:4147 __dev_xmit_skb net/core/dev.c:4262 [inline] __dev_queue_xmit+0x2998/0x46c0 net/core/dev.c:4798", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23086", "url": "https://ubuntu.com/security/CVE-2026-23086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: cap TX credit to local buffer size The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value. On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base. Introduce a small helper, virtio_transport_tx_buf_size(), that returns min(peer_buf_alloc, buf_alloc), and use it wherever we consume peer_buf_alloc. This ensures the effective TX window is bounded by both the peer's advertised buffer and our own buf_alloc (already clamped to buffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings. On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited. With this patch applied: Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive. Compatibility with non-virtio transports: - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer_* values; the remote side cannot enlarge those queues beyond what the local endpoint configured. - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peer_buf_alloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes. - The loopback path reuses virtio_transport_common.c, so it naturally follows the same semantics as the virtio transport. This change is limited to virtio_transport_common.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the \"remote window intersected with local policy\" behaviour that VMCI and Hyper-V already effectively have. [Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message]", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23069", "url": "https://ubuntu.com/security/CVE-2026-23069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential underflow in virtio_transport_get_credit() The credit calculation in virtio_transport_get_credit() uses unsigned arithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt); If the peer shrinks its advertised buffer (peer_buf_alloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle. Reuse virtio_transport_has_space() which already handles this case and add a comment to make it clear why we are doing that. [Stefano: use virtio_transport_has_space() instead of duplicating the code] [Stefano: tweak the commit message]", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23119", "url": "https://ubuntu.com/security/CVE-2026-23119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: provide a net pointer to __skb_flow_dissect() After 3cbf4ffba5ee (\"net: plumb network namespace into __skb_flow_dissect\") we have to provide a net pointer to __skb_flow_dissect(), either via skb->dev, skb->sk, or a user provided pointer. In the following case, syzbot was able to cook a bare skb. WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053 Call Trace: bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline] __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157 bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline] bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline] bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515 xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388 bpf_prog_run_xdp include/net/xdp.h:700 [inline] bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421 bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390 bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703 __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182 __do_sys_bpf kernel/bpf/syscall.c:6274 [inline] __se_sys_bpf kernel/bpf/syscall.c:6272 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23084", "url": "https://ubuntu.com/security/CVE-2026-23084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list When the parameter pmac_id_valid argument of be_cmd_get_mac_from_list() is set to false, the driver may request the PMAC_ID from the firmware of the network card, and this function will store that PMAC_ID at the provided address pmac_id. This is the contract of this function. However, there is a location within the driver where both pmac_id_valid == false and pmac_id == NULL are being passed. This could result in dereferencing a NULL pointer. To resolve this issue, it is necessary to pass the address of a stub variable to the function.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23124", "url": "https://ubuntu.com/security/CVE-2026-23124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: annotate data-race in ndisc_router_discovery() syzbot found that ndisc_router_discovery() could read and write in6_dev->ra_mtu without holding a lock [1] This looks fine, IFLA_INET6_RA_MTU is best effort. Add READ_ONCE()/WRITE_ONCE() to document the race. Note that we might also reject illegal MTU values (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch. [1] BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438 ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500 ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79 ... value changed: 0x00000000 -> 0xe5400659", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23121", "url": "https://ubuntu.com/security/CVE-2026-23121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mISDN: annotate data-race around dev->work dev->work can re read locklessly in mISDN_read() and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations. BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1: misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline] mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583 __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583 x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0: mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112 do_loop_readv_writev fs/read_write.c:847 [inline] vfs_readv+0x3fb/0x690 fs/read_write.c:1020 do_readv+0xe7/0x210 fs/read_write.c:1080 __do_sys_readv fs/read_write.c:1165 [inline] __se_sys_readv fs/read_write.c:1162 [inline] __x64_sys_readv+0x45/0x50 fs/read_write.c:1162 x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00000000 -> 0x00000001", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23126", "url": "https://ubuntu.com/security/CVE-2026-23126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: fix a race issue related to the operation on bpf_bound_progs list The netdevsim driver lacks a protection mechanism for operations on the bpf_bound_progs list. When the nsim_bpf_create_prog() performs list_add_tail, it is possible that nsim_bpf_destroy_prog() is simultaneously performs list_del. Concurrent operations on the list may lead to list corruption and trigger a kernel crash as follows: [ 417.290971] kernel BUG at lib/list_debug.c:62! [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 417.291007] Workqueue: events bpf_prog_free_deferred [ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0 [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8 [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246 [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000 [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180 [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003 [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20 [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000 [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000 [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0 [ 417.291088] PKRU: 55555554 [ 417.291091] Call Trace: [ 417.291096] [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim] [ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80 [ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0 [ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0 [ 417.291178] process_one_work+0x18a/0x3a0 [ 417.291188] worker_thread+0x27b/0x3a0 [ 417.291197] ? __pfx_worker_thread+0x10/0x10 [ 417.291207] kthread+0xe5/0x120 [ 417.291214] ? __pfx_kthread+0x10/0x10 [ 417.291221] ret_from_fork+0x31/0x50 [ 417.291230] ? __pfx_kthread+0x10/0x10 [ 417.291236] ret_from_fork_asm+0x1a/0x30 [ 417.291246] Add a mutex lock, to prevent simultaneous addition and deletion operations on the list.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23059", "url": "https://ubuntu.com/security/CVE-2026-23059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Sanitize payload size to prevent member overflow In qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_size reported by firmware is used to calculate the copy length into item->iocb. However, the iocb member is defined as a fixed-size 64-byte array within struct purex_item. If the reported frame_size exceeds 64 bytes, subsequent memcpy calls will overflow the iocb member boundary. While extra memory might be allocated, this cross-member write is unsafe and triggers warnings under CONFIG_FORTIFY_SOURCE. Fix this by capping total_bytes to the size of the iocb member (64 bytes) before allocation and copying. This ensures all copies remain within the bounds of the destination structure member.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23110", "url": "https://ubuntu.com/security/CVE-2026-23110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: Wake up the error handler when final completions race against each other The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance. First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count. This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands. Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task. This needs the call to scsi_host_busy() to be moved after host_failed is incremented to close the race condition.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23071", "url": "https://ubuntu.com/security/CVE-2026-23071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner. Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23068", "url": "https://ubuntu.com/security/CVE-2026-23068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-sprd-adi: Fix double free in probe error path The driver currently uses spi_alloc_host() to allocate the controller but registers it using devm_spi_register_controller(). If devm_register_restart_handler() fails, the code jumps to the put_ctlr label and calls spi_controller_put(). However, since the controller was registered via a devm function, the device core will automatically call spi_controller_put() again when the probe fails. This results in a double-free of the spi_controller structure. Fix this by switching to devm_spi_alloc_host() and removing the manual spi_controller_put() call.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23123", "url": "https://ubuntu.com/security/CVE-2026-23123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: interconnect: debugfs: initialize src_node and dst_node to empty strings The debugfs_create_str() API assumes that the string pointer is either NULL or points to valid kmalloc() memory. Leaving the pointer uninitialized can cause problems. Initialize src_node and dst_node to empty strings before creating the debugfs entries to guarantee that reads and writes are safe.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2025-71198", "url": "https://ubuntu.com/security/CVE-2025-71198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL event_spec field, indicating support for IIO events. However, event detection is not supported for all sensors, and if userspace tries to configure accelerometer wakeup events on a sensor device that does not support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL pointer when trying to write to the wakeup register. Define an additional struct iio_chan_spec array whose members have a NULL event_spec field, and use this array instead of st_lsm6dsx_acc_channels for sensors without event detection capability.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23113", "url": "https://ubuntu.com/security/CVE-2026-23113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't support ->read_iter(), loop_rw_iter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path: INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 Call Trace: context_switch kernel/sched/core.c:5256 [inline] __schedule+0x1139/0x6150 kernel/sched/core.c:6863 __schedule_loop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 do_wait_for_common kernel/sched/completion.c:100 [inline] __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 io_wq_exit_workers io_uring/io-wq.c:1328 [inline] io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 io_uring_files_cancel include/linux/io_uring.h:19 [inline] do_exit+0x2ce/0x2bd0 kernel/exit.c:911 do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 get_signal+0x2671/0x26d0 kernel/signal.c:3034 arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23062", "url": "https://ubuntu.com/security/CVE-2026-23062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs attributes: 1. Off-by-one error: The loop condition used '<=' instead of '<', causing access beyond array bounds. Since array indices are 0-based and go from 0 to instances_count-1, the loop should use '<'. 2. Missing NULL check: The code dereferenced attr_name_kobj->name without checking if attr_name_kobj was NULL, causing a null pointer dereference in min_length_show() and other attribute show functions. The panic occurred when fwupd tried to read BIOS configuration attributes: Oops: general protection fault [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg] Add a NULL check for attr_name_kobj before dereferencing and corrects the loop boundary to match the pattern used elsewhere in the driver.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23131", "url": "https://ubuntu.com/security/CVE-2026-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names The hp-bioscfg driver attempts to register kobjects with empty names when the HP BIOS returns attributes with empty name strings. This causes multiple kernel warnings: kobject: (00000000135fb5e6): attempted to be registered with empty name! WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310 Add validation in hp_init_bios_buffer_attribute() to check if the attribute name is empty after parsing it from the WMI buffer. If empty, log a debug message and skip registration of that attribute, allowing the module to continue processing other valid attributes.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23087", "url": "https://ubuntu.com/security/CVE-2026-23087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it in scsiback_remove().", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71197", "url": "https://ubuntu.com/security/CVE-2025-71197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: w1: therm: Fix off-by-one buffer overflow in alarms_store The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23105", "url": "https://ubuntu.com/security/CVE-2026-23105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use cl_is_active instead of relying on the child qdisc's qlen to determine class activation.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23103", "url": "https://ubuntu.com/security/CVE-2026-23103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close) This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause: 1) False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock. 2) Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23120", "url": "https://ubuntu.com/security/CVE-2026-23120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: avoid one data-race in l2tp_tunnel_del_work() We should read sk->sk_socket only when dealing with kernel sockets. syzbot reported the following data-race: BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sk_set_socket include/net/sock.h:2092 [inline] sock_orphan include/net/sock.h:2118 [inline] sk_common_release+0xae/0x230 net/core/sock.c:4003 udp_lib_close+0x15/0x20 include/net/udp.h:325 inet_release+0xce/0xf0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:662 [inline] sock_close+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/file_table.c:496 task_work_run+0x131/0x1a0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:44 [inline] exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340 worker_thread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 value changed: 0xffff88811b818000 -> 0x0000000000000000", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23083", "url": "https://ubuntu.com/security/CVE-2026-23083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor \"resubmit\"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23095", "url": "https://ubuntu.com/security/CVE-2026-23095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: Fix skb memleak with inner IP protocol 0. syzbot reported skb memleak below. [0] The repro generated a GUE packet with its inner protocol 0. gue_udp_recv() returns -guehdr->proto_ctype for \"resubmit\" in ip_protocol_deliver_rcu(), but this only works with non-zero protocol number. Let's drop such packets. Note that 0 is a valid number (IPv6 Hop-by-Hop Option). I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer: * no error * resubmit HOPOPT [0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm \"syz.0.17\", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4958 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_noprof+0x3b4/0x590 mm/slub.c:5270 __build_skb+0x23/0x60 net/core/skbuff.c:474 build_skb+0x20/0x190 net/core/skbuff.c:490 __tun_build_skb drivers/net/tun.c:1541 [inline] tun_build_skb+0x4a1/0xa40 drivers/net/tun.c:1636 tun_get_user+0xc12/0x2030 drivers/net/tun.c:1770 tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0xa7/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23125", "url": "https://ubuntu.com/security/CVE-2026-23125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace: sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127 The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently: - SCTP_CMD_PEER_INIT - SCTP_CMD_TIMER_STOP (T1_INIT) - SCTP_CMD_TIMER_START (T1_COOKIE) - SCTP_CMD_NEW_STATE (COOKIE_ECHOED) - SCTP_CMD_ASSOC_SHKEY - SCTP_CMD_GEN_COOKIE_ECHO If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user(). Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue. Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.", "cve_priority": "medium", "cve_public_date": "2026-02-14 15:16:00 UTC" }, { "cve": "CVE-2026-23099", "url": "https://ubuntu.com/security/CVE-2026-23099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: limit BOND_MODE_8023AD to Ethernet devices BOND_MODE_8023AD makes sense for ARPHRD_ETHER only. syzbot reported: BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline] BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497 CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: dump_stack_lvl+0xe8/0x150 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 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hw_addr_create net/core/dev_addr_lists.c:63 [inline] __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118 __dev_mc_add net/core/dev_addr_lists.c:868 [inline] dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886 bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180 do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963 do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnl_changelink net/core/rtnetlink.c:3776 [inline] __rtnl_newlink net/core/rtnetlink.c:3935 [inline] rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __sys_sendmsg+0x164/0x220 net/socket.c:2678 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307 do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332 entry_SYSENTER_compat_after_hwframe+0x84/0x8e The buggy address belongs to the variable: lacpdu_mcast_addr+0x0/0x40", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71194", "url": "https://ubuntu.com/security/CVE-2025-71194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock in wait_current_trans() due to ignored transaction type When wait_current_trans() is called during start_transaction(), it currently waits for a blocked transaction without considering whether the given transaction type actually needs to wait for that particular transaction state. The btrfs_blocked_trans_types[] array already defines which transaction types should wait for which transaction states, but this check was missing in wait_current_trans(). This can lead to a deadlock scenario involving two transactions and pending ordered extents: 1. Transaction A is in TRANS_STATE_COMMIT_DOING state 2. A worker processing an ordered extent calls start_transaction() with TRANS_JOIN 3. join_transaction() returns -EBUSY because Transaction A is in TRANS_STATE_COMMIT_DOING 4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes 5. A new Transaction B is created (TRANS_STATE_RUNNING) 6. The ordered extent from step 2 is added to Transaction B's pending ordered extents 7. Transaction B immediately starts commit by another task and enters TRANS_STATE_COMMIT_START 8. The worker finally reaches wait_current_trans(), sees Transaction B in TRANS_STATE_COMMIT_START (a blocked state), and waits unconditionally 9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START according to btrfs_blocked_trans_types[] 10. Transaction B is waiting for pending ordered extents to complete 11. Deadlock: Transaction B waits for ordered extent, ordered extent waits for Transaction B This can be illustrated by the following call stacks: CPU0 CPU1 btrfs_finish_ordered_io() start_transaction(TRANS_JOIN) join_transaction() # -EBUSY (Transaction A is # TRANS_STATE_COMMIT_DOING) # Transaction A completes # Transaction B created # ordered extent added to # Transaction B's pending list btrfs_commit_transaction() # Transaction B enters # TRANS_STATE_COMMIT_START # waiting for pending ordered # extents wait_current_trans() # waits for Transaction B # (should not wait!) Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered extents: __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 btrfs_commit_transaction+0xbf7/0xda0 [btrfs] btrfs_sync_file+0x342/0x4d0 [btrfs] __x64_sys_fdatasync+0x4b/0x80 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Task kworker in wait_current_trans waiting for transaction commit: Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs] __schedule+0x2e7/0x8a0 schedule+0x64/0xe0 wait_current_trans+0xb0/0x110 [btrfs] start_transaction+0x346/0x5b0 [btrfs] btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs] btrfs_work_helper+0xe8/0x350 [btrfs] process_one_work+0x1d3/0x3c0 worker_thread+0x4d/0x3e0 kthread+0x12d/0x150 ret_from_fork+0x1f/0x30 Fix this by passing the transaction type to wait_current_trans() and checking btrfs_blocked_trans_types[cur_trans->state] against the given type before deciding to wait. This ensures that transaction types which are allowed to join during certain blocked states will not unnecessarily wait and cause deadlocks.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71185", "url": "https://ubuntu.com/security/CVE-2025-71185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23026", "url": "https://ubuntu.com/security/CVE-2026-23026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config() Fix a memory leak in gpi_peripheral_config() where the original memory pointed to by gchan->config could be lost if krealloc() fails. The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds. Found via static analysis and code review.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71188", "url": "https://ubuntu.com/security/CVE-2025-71188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71163", "url": "https://ubuntu.com/security/CVE-2025-71163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix device leaks on compat bind and unbind Make sure to drop the reference taken when looking up the idxd device as part of the compat bind and unbind sysfs interface.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71189", "url": "https://ubuntu.com/security/CVE-2025-71189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw: dmamux: fix OF node leak on route allocation failure Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71190", "url": "https://ubuntu.com/security/CVE-2025-71190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: bcm-sba-raid: fix device leak on probe Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71191", "url": "https://ubuntu.com/security/CVE-2025-71191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 (\"dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()\") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23049", "url": "https://ubuntu.com/security/CVE-2026-23049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel The connector type for the DataImage SCF0700C48GGU18 panel is missing and devm_drm_panel_bridge_add() requires connector type to be set. This leads to a warning and a backtrace in the kernel log and panel does not work: \" WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8 \" The warning is triggered by a check for valid connector type in devm_drm_panel_bridge_add(). If there is no valid connector type set for a panel, the warning is printed and panel is not added. Fill in the missing connector type to fix the warning and make the panel operational once again.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23144", "url": "https://ubuntu.com/security/CVE-2026-23144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure When a context DAMON sysfs directory setup is failed after setup of attrs/ directory, subdirectories of attrs/ directory are not cleaned up. As a result, DAMON sysfs interface is nearly broken until the system reboots, and the memory for the unremoved directory is leaked. Cleanup the directories under such failures.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-23145", "url": "https://ubuntu.com/security/CVE-2026-23145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref The error branch for ext4_xattr_inode_update_ref forget to release the refcount for iloc.bh. Find this when review code.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22997", "url": "https://ubuntu.com/security/CVE-2026-22997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the second rts Since j1939_session_deactivate_activate_next() in j1939_tp_rxtimer() is called only when the timer is enabled, we need to call j1939_session_deactivate_activate_next() if we cancelled the timer. Otherwise, refcount for j1939_session leaks, which will later appear as | unregister_netdevice: waiting for vcan0 to become free. Usage count = 2. problem.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23031", "url": "https://ubuntu.com/security/CVE-2026-23031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in gs_can_close(). Fix the memory leak by anchoring the URB in the gs_usb_receive_bulk_callback() to the parent->rx_submitted anchor.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23032", "url": "https://ubuntu.com/security/CVE-2026-23032", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: null_blk: fix kmemleak by releasing references to fault configfs items When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk driver sets up fault injection support by creating the timeout_inject, requeue_inject, and init_hctx_fault_inject configfs items as children of the top-level nullbX configfs group. However, when the nullbX device is removed, the references taken to these fault-config configfs items are not released. As a result, kmemleak reports a memory leak, for example: unreferenced object 0xc00000021ff25c40 (size 32): comm \"mkdir\", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ec Fix this by explicitly releasing the references to the fault-config configfs items when dropping the reference to the top-level nullbX configfs group.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23033", "url": "https://ubuntu.com/security/CVE-2026-23033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71196", "url": "https://ubuntu.com/security/CVE-2025-71196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: stm32-usphyc: Fix off by one in probe() The \"index\" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements. So if it is equal to usbphyc->nphys then it is one element out of bounds. The \"index\" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug. Change the > to >=.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71193", "url": "https://ubuntu.com/security/CVE-2025-71193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qusb2: Fix NULL pointer dereference on early suspend Enabling runtime PM before attaching the QPHY instance as driver data can lead to a NULL pointer dereference in runtime PM callbacks that expect valid driver data. There is a small window where the suspend callback may run after PM runtime enabling and before runtime forbid. This causes a sporadic crash during boot: ``` Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1 [...] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPT Workqueue: pm pm_runtime_work pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2] lr : pm_generic_runtime_suspend+0x2c/0x44 [...] ``` Attach the QPHY instance as driver data before enabling runtime PM to prevent NULL pointer dereference in runtime PM callbacks. Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2025-71162", "url": "https://ubuntu.com/security/CVE-2025-71162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegra_adma_terminate_all() before the vchan completion tasklet finishes accessing it. The race condition follows this sequence: 1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegra_adma_terminate_all() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchan_complete() which attempts to access the already-freed memory Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchan_complete() runs. Fix this by properly synchronizing the virtual channel completion: - Calling vchan_terminate_vdesc() in tegra_adma_stop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegra_adma_synchronize() that calls vchan_synchronize() which kills any pending tasklets and frees any terminated descriptors. Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchan_complete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0 [ 337.427562] Call trace: [ 337.427564] dump_backtrace+0x0/0x320 [ 337.427571] show_stack+0x20/0x30 [ 337.427575] dump_stack_lvl+0x68/0x84 [ 337.427584] print_address_description.constprop.0+0x74/0x2b8 [ 337.427590] kasan_report+0x1f4/0x210 [ 337.427598] __asan_load8+0xa0/0xd0 [ 337.427603] vchan_complete+0x124/0x3b0 [ 337.427609] tasklet_action_common.constprop.0+0x190/0x1d0 [ 337.427617] tasklet_action+0x30/0x40 [ 337.427623] __do_softirq+0x1a0/0x5c4 [ 337.427628] irq_exit+0x110/0x140 [ 337.427633] handle_domain_irq+0xa4/0xe0 [ 337.427640] gic_handle_irq+0x64/0x160 [ 337.427644] call_on_irq_stack+0x20/0x4c [ 337.427649] do_interrupt_handler+0x7c/0x90 [ 337.427654] el1_interrupt+0x30/0x80 [ 337.427659] el1h_64_irq_handler+0x18/0x30 [ 337.427663] el1h_64_irq+0x7c/0x80 [ 337.427667] cpuidle_enter_state+0xe4/0x540 [ 337.427674] cpuidle_enter+0x54/0x80 [ 337.427679] do_idle+0x2e0/0x380 [ 337.427685] cpu_startup_entry+0x2c/0x70 [ 337.427690] rest_init+0x114/0x130 [ 337.427695] arch_call_rest_init+0x18/0x24 [ 337.427702] start_kernel+0x380/0x3b4 [ 337.427706] __primary_switched+0xc0/0xc8", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2025-71195", "url": "https://ubuntu.com/security/CVE-2025-71195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: xilinx: xdma: Fix regmap max_register The max_register field is assigned the size of the register memory region instead of the offset of the last register. The result is that reading from the regmap via debugfs can cause a segmentation fault: tail /sys/kernel/debug/regmap/xdma.1.auto/registers Unable to handle kernel paging request at virtual address ffff800082f70000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault [...] Call trace: regmap_mmio_read32le+0x10/0x30 _regmap_bus_reg_read+0x74/0xc0 _regmap_read+0x68/0x198 regmap_read+0x54/0x88 regmap_read_debugfs+0x140/0x380 regmap_map_read_file+0x30/0x48 full_proxy_read+0x68/0xc8 vfs_read+0xcc/0x310 ksys_read+0x7c/0x120 __arm64_sys_read+0x24/0x40 invoke_syscall.constprop.0+0x64/0x108 do_el0_svc+0xb0/0xd8 el0_svc+0x38/0x130 el0t_64_sync_handler+0x120/0x138 el0t_64_sync+0x194/0x198 Code: aa1e03e9 d503201f f9400000 8b214000 (b9400000) ---[ end trace 0000000000000000 ]--- note: tail[1217] exited with irqs disabled note: tail[1217] exited with preempt_count 1 Segmentation fault", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23006", "url": "https://ubuntu.com/security/CVE-2026-23006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tlv320adcx140: fix null pointer The \"snd_soc_component\" in \"adcx140_priv\" was only used once but never set. It was only used for reaching \"dev\" which is already present in \"adcx140_priv\".", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-22999", "url": "https://ubuntu.com/security/CVE-2026-22999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: do not free existing class in qfq_change_class() Fixes qfq_change_class() error case. cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23010", "url": "https://ubuntu.com/security/CVE-2026-23010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix use-after-free in inet6_addr_del(). syzbot reported use-after-free of inet6_ifaddr in inet6_addr_del(). [0] The cited commit accidentally moved ipv6_del_addr() for mngtmpaddr before reading its ifp->flags for temporary addresses in inet6_addr_del(). Let's move ipv6_del_addr() down to fix the UAF. [0]: BUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593 CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 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 inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f164cf8f749 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:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749 RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003 RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 Allocated by task 9593: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6099: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2540 [inline] slab_free_freelist_hook mm/slub.c:2569 [inline] slab_free_bulk mm/slub.c:6696 [inline] kmem_cache_free_bulk mm/slub.c:7383 [inline] kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362 kfree_bulk include/linux/slab.h:830 [inline] kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523 kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline] kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801 process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257 process_scheduled_works kernel/workqu ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23054", "url": "https://ubuntu.com/security/CVE-2026-23054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hv_netvsc: reject RSS hash key programming without RX indirection table RSS configuration requires a valid RX indirection table. When the device reports a single receive queue, rndis_filter_device_add() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang. Fix this by gating netvsc_set_rxfh() on ndc->rx_table_sz and return -EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device capabilities and prevents incorrect behavior.", "cve_priority": "medium", "cve_public_date": "2026-02-04 17:16:00 UTC" }, { "cve": "CVE-2026-23011", "url": "https://ubuntu.com/security/CVE-2026-23011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device. [1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23001", "url": "https://ubuntu.com/security/CVE-2026-23001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix possible UAF in macvlan_forward_source() Add RCU protection on (struct macvlan_source_entry)->vlan. Whenever macvlan_hash_del_source() is called, we must clear entry->vlan pointer before RCU grace period starts. This allows macvlan_forward_source() to skip over entries queued for freeing. Note that macvlan_dev are already RCU protected, as they are embedded in a standard netdev (netdev_priv(ndev)). https: //lore.kernel.org/netdev/695fb1e8.050a0220.1c677c.039f.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23003", "url": "https://ubuntu.com/security/CVE-2026-23003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1]. Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull(). [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 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:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23141", "url": "https://ubuntu.com/security/CVE-2026-23141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22998", "url": "https://ubuntu.com/security/CVE-2026-22998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec Commit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs. The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command. Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated", "cve_priority": "medium", "cve_public_date": "2026-01-25 15:15:00 UTC" }, { "cve": "CVE-2026-23037", "url": "https://ubuntu.com/security/CVE-2026-23037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: allow partial RX URB allocation to succeed When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked. As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error. Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23038", "url": "https://ubuntu.com/security/CVE-2026-23038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71184", "url": "https://ubuntu.com/security/CVE-2025-71184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix NULL dereference on root when tracing inode eviction When evicting an inode the first thing we do is to setup tracing for it, which implies fetching the root's id. But in btrfs_evict_inode() the root might be NULL, as implied in the next check that we do in btrfs_evict_inode(). Hence, we either should set the ->root_objectid to 0 in case the root is NULL, or we move tracing setup after checking that the root is not NULL. Setting the rootid to 0 at least gives us the possibility to trace this call even in the case when the root is NULL, so that's the solution taken here.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71182", "url": "https://ubuntu.com/security/CVE-2025-71182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: j1939: make j1939_session_activate() fail if device is no longer registered syzbot is still reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 even after commit 93a27b5891b8 (\"can: j1939: add missing calls in NETDEV_UNREGISTER notification handler\") was added. A debug printk() patch found that j1939_session_activate() can succeed even after j1939_cancel_active_session() from j1939_netdev_notify(NETDEV_UNREGISTER) has completed. Since j1939_cancel_active_session() is processed with the session list lock held, checking ndev->reg_state in j1939_session_activate() with the session list lock held can reliably close the race window.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71160", "url": "https://ubuntu.com/security/CVE-2025-71160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid chain re-validation if possible Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..] Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps). But there are cases where we could avoid revalidation. Consider: 1 input -> j2 -> j3 2 input -> j2 -> j3 3 input -> j1 -> j2 -> j3 Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3. This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size. We also need to update all reachable chains with the new largest observed call depth. Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains. For example, the masquerade expression can only be called from NAT postrouting base chains. Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22994", "url": "https://ubuntu.com/security/CVE-2026-22994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix reference count leak in bpf_prog_test_run_xdp() syzbot is reporting unregister_netdevice: waiting for sit0 to become free. Usage count = 2 problem. A debug printk() patch found that a refcount is obtained at xdp_convert_md_to_buff() from bpf_prog_test_run_xdp(). According to commit ec94670fcb3b (\"bpf: Support specifying ingress via xdp_md context in BPF_PROG_TEST_RUN\"), the refcount obtained by xdp_convert_md_to_buff() will be released by xdp_convert_buff_to_md(). Therefore, we can consider that the error handling path introduced by commit 1c1949982524 (\"bpf: introduce frags support to bpf_prog_test_run_xdp()\") forgot to call xdp_convert_buff_to_md().", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-23140", "url": "https://ubuntu.com/security/CVE-2026-23140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Subtract size of xdp_frame from allowed metadata size The xdp_frame structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpf_test_run, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom). If userspace supplies such a large metadata size in live packet mode, the xdp_update_frame_from_buff() call in xdp_test_run_init_page() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff. The commit in the Fixes tag fixed a related bug where the second check in xdp_update_frame_from_buff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-71192", "url": "https://ubuntu.com/security/CVE-2025-71192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix a double free in snd_ac97_controller_register() If ac97_add_adapter() fails, put_device() is the correct way to drop the device reference. kfree() is not required. Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do the cleanup. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-02-04 16:16:00 UTC" }, { "cve": "CVE-2026-23021", "url": "https://ubuntu.com/security/CVE-2026-23021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: fix memory leak in update_eth_regs_async() When asynchronously writing to the device registers and if usb_submit_urb() fail, the code fail to release allocated to this point resources.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-22976", "url": "https://ubuntu.com/security/CVE-2026-22976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset `qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the class itself is active. Two qfq_class objects may point to the same leaf_qdisc. This happens when: 1. one QFQ qdisc is attached to the dev as the root qdisc, and 2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get() / qdisc_put()) and is pending to be destroyed, as in function tc_new_tfilter. When packets are enqueued through the root QFQ qdisc, the shared leaf_qdisc->q.qlen increases. At the same time, the second QFQ qdisc triggers qdisc_put and qdisc_destroy: the qdisc enters qfq_reset() with its own q->q.qlen == 0, but its class's leaf qdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivate an inactive aggregate and trigger a null-deref in qfq_deactivate_agg: [ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 0.903571] #PF: supervisor write access in kernel mode [ 0.903860] #PF: error_code(0x0002) - not-present page [ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0 [ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI [ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE [ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2)) [ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0 Code starting with the faulting instruction =========================================== 0:\t0f 84 4d 01 00 00 \tje 0x153 6:\t48 89 70 18 \tmov %rsi,0x18(%rax) a:\t8b 4b 10 \tmov 0x10(%rbx),%ecx d:\t48 c7 c2 ff ff ff ff \tmov $0xffffffffffffffff,%rdx 14:\t48 8b 78 08 \tmov 0x8(%rax),%rdi 18:\t48 d3 e2 \tshl %cl,%rdx 1b:\t48 21 f2 \tand %rsi,%rdx 1e:\t48 2b 13 \tsub (%rbx),%rdx 21:\t48 8b 30 \tmov (%rax),%rsi 24:\t48 d3 ea \tshr %cl,%rdx 27:\t8b 4b 18 \tmov 0x18(%rbx),%ecx \t... [ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246 [ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000 [ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000 [ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000 [ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880 [ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000 [ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0 [ 0.910247] PKRU: 55555554 [ 0.910391] Call Trace: [ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485) [ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036) [ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076) [ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447) [ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958) [ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861) [ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550) [ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344) [ 0.912296] ? __alloc_skb (net/core/skbuff.c:706) [ 0.912484] netlink_sendmsg (net/netlink/af ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-21 07:16:00 UTC" }, { "cve": "CVE-2026-22979", "url": "https://ubuntu.com/security/CVE-2026-22979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix memory leak in skb_segment_list for GRO packets When skb_segment_list() is called during packet forwarding, it handles packets that were aggregated by the GRO engine. Historically, the segmentation logic in skb_segment_list assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments. Prior to commit ed4cccef64c1 (\"gro: fix ownership transfer\"), this truesize subtraction in skb_segment_list() was valid because fragments still carry a reference to the original socket. However, commit ed4cccef64c1 (\"gro: fix ownership transfer\") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skb_segment_list() was never updated. As a result, the current code unconditionally adds each fragment's truesize to delta_truesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes sk_wmem_alloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak. The leak can be observed via KMEMLEAK when tearing down the networking environment: unreferenced object 0xffff8881e6eb9100 (size 2048): comm \"ping\", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0 Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST packets constructed by GRO, the truesize adjustment is removed. The call to skb_release_head_state() must be preserved. As documented in commit cf673ed0e057 (\"net: fix fraglist segmentation reference count leak\"), it is still required to correctly drop references to SKB extensions that may be overwritten during __copy_skb_header().", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22977", "url": "https://ubuntu.com/security/CVE-2026-22977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sock: fix hardened usercopy panic in sock_recv_errqueue skbuff_fclone_cache was created without defining a usercopy region, [1] unlike skbuff_head_cache which properly whitelists the cb[] field. [2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is enabled and the kernel attempts to copy sk_buff.cb data to userspace via sock_recv_errqueue() -> put_cmsg(). The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone() (from skbuff_fclone_cache) [1] 2. The skb is cloned via skb_clone() using the pre-allocated fclone [3] 3. The cloned skb is queued to sk_error_queue for timestamp reporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE) 5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb [4] 6. __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist [5] When cloned skbs allocated from skbuff_fclone_cache are used in the socket error queue, accessing the sock_exterr_skb structure in skb->cb via put_cmsg() triggers a usercopy hardening violation: [ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)! [ 5.382796] kernel BUG at mm/usercopy.c:102! [ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7 [ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80 [ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490 [ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246 [ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74 [ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0 [ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74 [ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001 [ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00 [ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000 [ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0 [ 5.384903] PKRU: 55555554 [ 5.384903] Call Trace: [ 5.384903] [ 5.384903] __check_heap_object+0x9a/0xd0 [ 5.384903] __check_object_size+0x46c/0x690 [ 5.384903] put_cmsg+0x129/0x5e0 [ 5.384903] sock_recv_errqueue+0x22f/0x380 [ 5.384903] tls_sw_recvmsg+0x7ed/0x1960 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5.384903] ? schedule+0x6d/0x270 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5.384903] ? mutex_unlock+0x81/0xd0 [ 5.384903] ? __pfx_mutex_unlock+0x10/0x10 [ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10 [ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0 [ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5 The crash offset 296 corresponds to skb2->cb within skbuff_fclones: - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee) This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure. [1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885 [2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104 [3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566 [4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491 [5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719", "cve_priority": "medium", "cve_public_date": "2026-01-21 14:16:00 UTC" }, { "cve": "CVE-2026-22982", "url": "https://ubuntu.com/security/CVE-2026-22982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: Fix crash when adding interface under a lag Commit 15faa1f67ab4 (\"lan966x: Fix crash when adding interface under a lag\") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelot_set_aggr_pgids() function in the ocelot driver has similar logic and is susceptible to the same crash. This issue specifically affects the ocelot_vsc7514.c frontend, which leaves unused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports. Fix this by checking if the port pointer is valid before accessing it.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-23019", "url": "https://ubuntu.com/security/CVE-2026-23019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix NULL dereference on devlink_alloc() failure devlink_alloc() may return NULL on allocation failure, but prestera_devlink_alloc() unconditionally calls devlink_priv() on the returned pointer. This leads to a NULL pointer dereference if devlink allocation fails. Add a check for a NULL devlink pointer and return NULL early to avoid the crash.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23139", "url": "https://ubuntu.com/security/CVE-2026-23139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: update last_gc only when GC has been performed Currently last_gc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely. Update the last_gc value only when a GC has been actually performed.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2025-40149", "url": "https://ubuntu.com/security/CVE-2025-40149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock(). get_netdev_for_sock() is called during setsockopt(), so not under RCU. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the only ->ndo_sk_get_lower_dev() user is bond_sk_get_lower_dev(), which uses RCU.", "cve_priority": "medium", "cve_public_date": "2025-11-12 11:15:00 UTC" }, { "cve": "CVE-2025-68803", "url": "https://ubuntu.com/security/CVE-2025-68803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: NFSv4 file creation neglects setting ACL An NFSv4 client that sets an ACL with a named principal during file creation retrieves the ACL afterwards, and finds that it is only a default ACL (based on the mode bits) and not the ACL that was requested during file creation. This violates RFC 8881 section 6.4.1.3: \"the ACL attribute is set as given\". The issue occurs in nfsd_create_setattr(), which calls nfsd_attrs_valid() to determine whether to call nfsd_setattr(). However, nfsd_attrs_valid() checks only for iattr changes and security labels, but not POSIX ACLs. When only an ACL is present, the function returns false, nfsd_setattr() is skipped, and the POSIX ACL is never applied to the inode. Subsequently, when the client retrieves the ACL, the server finds no POSIX ACL on the inode and returns one generated from the file's mode bits rather than returning the originally-specified ACL.", "cve_priority": "medium", "cve_public_date": "2026-01-13 16:16:00 UTC" }, { "cve": "CVE-2026-23047", "url": "https://ubuntu.com/security/CVE-2026-23047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: make calc_target() set t->paused, not just clear it Currently calc_target() clears t->paused if the request shouldn't be paused anymore, but doesn't ever set t->paused even though it's able to determine when the request should be paused. Setting t->paused is left to __submit_request() which is fine for regular requests but doesn't work for linger requests -- since __submit_request() doesn't operate on linger requests, there is nowhere for lreq->t.paused to be set. One consequence of this is that watches don't get reestablished on paused -> unpaused transitions in cases where requests have been paused long enough for the (paused) unwatch request to time out and for the subsequent (re)watch request to enter the paused state. On top of the watch not getting reestablished, rbd_reregister_watch() gets stuck with rbd_dev->watch_mutex held: rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_wait It's waiting for lreq->reg_commit_wait to be completed, but for that to happen the respective request needs to end up on need_resend_linger list and be kicked when requests are unpaused. There is no chance for that if the request in question is never marked paused in the first place. The fact that rbd_dev->watch_mutex remains taken out forever then prevents the image from getting unmapped -- \"rbd unmap\" would inevitably hang in D state on an attempt to grab the mutex.", "cve_priority": "medium", "cve_public_date": "2026-02-04 16:16:00 UTC" }, { "cve": "CVE-2026-23136", "url": "https://ubuntu.com/security/CVE-2026-23136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reset sparse-read state in osd_fault() When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state. If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state.", "cve_priority": "medium", "cve_public_date": "2026-02-14 16:15:00 UTC" }, { "cve": "CVE-2026-22992", "url": "https://ubuntu.com/security/CVE-2026-22992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: return the handler error from mon_handle_auth_done() Currently any error from ceph_auth_handle_reply_done() is propagated via finish_auth() but isn't returned from mon_handle_auth_done(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setup_crypto() and later lead to a NULL pointer dereference inside of prepare_auth_signature().", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22991", "url": "https://ubuntu.com/security/CVE-2026-22991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: make free_choose_arg_map() resilient to partial allocation free_choose_arg_map() may dereference a NULL pointer if its caller fails after a partial allocation. For example, in decode_choose_args(), if allocation of arg_map->args fails, execution jumps to the fail label and free_choose_arg_map() is called. Since arg_map->size is updated to a non-zero value before memory allocation, free_choose_arg_map() will iterate over arg_map->args and dereference a NULL pointer. To prevent this potential NULL pointer dereference and make free_choose_arg_map() more resilient, add checks for pointers before iterating.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22990", "url": "https://ubuntu.com/security/CVE-2026-22990", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: replace overzealous BUG_ON in osdmap_apply_incremental() If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22984", "url": "https://ubuntu.com/security/CVE-2026-22984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in handle_auth_done() Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout. [ idryomov: changelog ]", "cve_priority": "high", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2026-22978", "url": "https://ubuntu.com/security/CVE-2026-22978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: avoid kernel-infoleak from struct iw_point struct iw_point has a 32bit hole on 64bit arches. struct iw_point { void __user *pointer; /* Pointer to the data (in user space) */ __u16 length; /* number of fields or size in bytes */ __u16 flags; /* Optional params */ }; Make sure to zero the structure to avoid disclosing 32bits of kernel data to user space.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2025-71180", "url": "https://ubuntu.com/security/CVE-2025-71180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: counter: interrupt-cnt: Drop IRQF_NO_THREAD flag An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as CONFIG_PROVE_RAW_LOCK_NESTING warns: ============================= [ BUG: Invalid wait context ] 6.18.0-rc1+git... #1 ----------------------------- some-user-space-process/1251 is trying to lock: (&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter] other info that might help us debug this: context-{2:2} no locks held by some-user-space-process/.... stack backtrace: CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT Call trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq ... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an alternative to switching to raw_spinlock_t, because the latter would limit all potential nested locks to raw_spinlock_t only.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2025-71183", "url": "https://ubuntu.com/security/CVE-2025-71183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: always detect conflicting inodes when logging inode refs After rename exchanging (either with the rename exchange operation or regular renames in multiple non-atomic steps) two inodes and at least one of them is a directory, we can end up with a log tree that contains only of the inodes and after a power failure that can result in an attempt to delete the other inode when it should not because it was not deleted before the power failure. In some case that delete attempt fails when the target inode is a directory that contains a subvolume inside it, since the log replay code is not prepared to deal with directory entries that point to root items (only inode items). 1) We have directories \"dir1\" (inode A) and \"dir2\" (inode B) under the same parent directory; 2) We have a file (inode C) under directory \"dir1\" (inode A); 3) We have a subvolume inside directory \"dir2\" (inode B); 4) All these inodes were persisted in a past transaction and we are currently at transaction N; 5) We rename the file (inode C), so at btrfs_log_new_name() we update inode C's last_unlink_trans to N; 6) We get a rename exchange for \"dir1\" (inode A) and \"dir2\" (inode B), so after the exchange \"dir1\" is inode B and \"dir2\" is inode A. During the rename exchange we call btrfs_log_new_name() for inodes A and B, but because they are directories, we don't update their last_unlink_trans to N; 7) An fsync against the file (inode C) is done, and because its inode has a last_unlink_trans with a value of N we log its parent directory (inode A) (through btrfs_log_all_parents(), called from btrfs_log_inode_parent()). 8) So we end up with inode B not logged, which now has the old name of inode A. At copy_inode_items_to_log(), when logging inode A, we did not check if we had any conflicting inode to log because inode A has a generation lower than the current transaction (created in a past transaction); 9) After a power failure, when replaying the log tree, since we find that inode A has a new name that conflicts with the name of inode B in the fs tree, we attempt to delete inode B... this is wrong since that directory was never deleted before the power failure, and because there is a subvolume inside that directory, attempting to delete it will fail since replay_dir_deletes() and btrfs_unlink_inode() are not prepared to deal with dir items that point to roots instead of inodes. When that happens the mount fails and we get a stack trace like the following: [87.2314] BTRFS info (device dm-0): start tree-log replay [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259 [87.2332] ------------[ cut here ]------------ [87.2338] BTRFS: Transaction aborted (error -2) [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2368] Modules linked in: btrfs loop dm_thin_pool (...) [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G W 6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full) [87.2489] Tainted: [W]=WARN [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs] [87.2538] Code: c0 89 04 24 (...) [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286 [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000 [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840 [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0 [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10 [87.2618] FS: 00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000 [87. ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-23020", "url": "https://ubuntu.com/security/CVE-2026-23020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: 3com: 3c59x: fix possible null dereference in vortex_probe1() pdev can be null and free_ring: can be called in 1297 with a null pdev.", "cve_priority": "medium", "cve_public_date": "2026-01-31 12:16:00 UTC" }, { "cve": "CVE-2026-22980", "url": "https://ubuntu.com/security/CVE-2026-22980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: provide locking for v4_end_grace Writing to v4_end_grace can race with server shutdown and result in memory being accessed after it was freed - reclaim_str_hashtbl in particularly. We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is held while client_tracking_op->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4_end_grace, resulting in a deadlock. nfsd4_end_grace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4_end_grace() might access. However, we must be sure that writing to v4_end_grace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->client_lock. It is set only while it is safe to make client tracking calls, and v4_end_grace only schedules work while the flag is set with the spinlock held. So this patch adds a nfsd_net field \"client_tracking_active\" which is set as described. Another field \"grace_end_forced\", is set when v4_end_grace is written. After this is set, and providing client_tracking_active is set, the laundromat is scheduled. This \"grace_end_forced\" field bypasses other checks for whether the grace period has finished. This resolves a race which can result in use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-01-23 16:15:00 UTC" }, { "cve": "CVE-2024-50004", "url": "https://ubuntu.com/security/CVE-2024-50004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35 [WHY & HOW] Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override to match HW spec. (cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2026-23274", "url": "https://ubuntu.com/security/CVE-2026-23274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.", "cve_priority": "medium", "cve_public_date": "2026-03-20 09:16:00 UTC" }, { "cve": "CVE-2026-23351", "url": "https://ubuntu.com/security/CVE-2026-23351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-23231", "url": "https://ubuntu.com/security/CVE-2026-23231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.", "cve_priority": "high", "cve_public_date": "2026-03-04 13:15:00 UTC" }, { "cve": "CVE-2026-23209", "url": "https://ubuntu.com/security/CVE-2026-23209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source(). With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.", "cve_priority": "medium", "cve_public_date": "2026-02-14 17:15:00 UTC" }, { "cve": "CVE-2026-23112", "url": "https://ubuntu.com/security/CVE-2026-23112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.", "cve_priority": "high", "cve_public_date": "2026-02-13 14:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-112.112 -proposed tracker (LP: #2147982)", "", " * Canonical Kmod 2025 key rotation (LP: #2147447)", " - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing", " extensible", " - [Packaging] ubuntu-compatible-signing -- allow consumption of positive", " certs", " - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key", " - [Config] prepare for Canonical Kmod key rotation", " - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key", "", " * Remount ext4 to readonly with data=journal mode may dump call trace", " (LP: #2147400)", " - ext4: fix stale xarray tags after writeback", "", " * Compile error due to nonexistent struct member with CONFIG_PCI_EPF_TEST", " (LP: #2147065)", " - SAUCE: Revert \"PCI: endpoint: pci-epf-test: Limit PCIe BAR size for", " fixed BARs\"", "", " * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)", " - drm/amdgpu: validate the flush_gpu_tlb_pasid()", " - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841)", " - x86/kfence: fix booting on 32bit non-PAE systems", " - platform/x86: intel_telemetry: Fix swapped arrays in PSS output", " - pmdomain: qcom: rpmpd: fix off-by-one error in clamping to the highest", " state", " - pmdomain: imx8mp-blk-ctrl: Keep gpc power domain on for system wakeup", " - pmdomain: imx: gpcv2: Fix the imx8mm gpu hang due to wrong adb400 reset", " - pmdomain: imx8mp-blk-ctrl: Keep usb phy power domain on for system", " wakeup", " - rbd: check for EOD after exclusive lock is ensured to be held", " - ARM: 9468/1: fix memset64() on big-endian", " - hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()", " - binder: fix BR_FROZEN_REPLY error log", " - binderfs: fix ida_alloc_max() upper bound", " - KVM: selftests: Add -U_FORTIFY_SOURCE to avoid some unpredictable test", " failures", " - tracing: Fix ftrace event field alignments", " - net: usb: sr9700: support devices with virtual driver CD", " - block,bfq: fix aux stat accumulation destination", " - LoongArch: Set correct protection_map[] for VM_NONE/VM_SHARED", " - HID: intel-ish-hid: Update ishtp bus match to support device ID table", " - HID: multitouch: add MT_QUIRK_STICKY_FINGERS to MT_CLS_VTL", " - HID: intel-ish-hid: Reset enum_devices_done before enumeration", " - HID: playstation: Center initial joystick axes to prevent spurious", " events", " - ALSA: hda/realtek: add HP Laptop 15s-eq1xxx mute LED quirk", " - netfilter: replace -EEXIST with -EBUSY", " - HID: quirks: Add another Chicony HP 5MP Cameras to hid_ignore_list", " - HID: Apply quirk HID_QUIRK_ALWAYS_POLL to Edifier QR30 (2d99:a101)", " - ring-buffer: Avoid softlockup in ring_buffer_resize() during memory free", " - wifi: mac80211: collect station statistics earlier when disconnect", " - ASoC: davinci-evm: Fix reference leak in davinci_evm_probe", " - ASoC: amd: yc: Fix microphone on ASUS M6500RE", " - ASoC: tlv320adcx140: Propagate error codes during probe", " - spi: hisi-kunpeng: Fixed the wrong debugfs node name in hisi_spi debugfs", " initialization", " - wifi: cfg80211: Fix bitrate calculation overflow for HE rates", " - ALSA: hda/realtek: Fix headset mic for TongFang X6AR55xU", " - wifi: mac80211: correctly check if CSA is active", " - wifi: mac80211: don't increment crypto_tx_tailroom_needed_cnt twice", " - platform/x86: intel_telemetry: Fix PSS event register mask", " - platform/x86: hp-bioscfg: Skip empty attribute names", " - net: add skb_header_pointer_careful() helper", " - net: don't touch dev->stats in BPF redirect paths", " - tipc: use kfree_sensitive() for session key material", " - net: ethernet: adi: adin1110: Check return value of", " devm_gpiod_get_optional() in adin1110_check_spi()", " - drm/mgag200: fix mgag200_bmc_stop_scanout()", " - hwmon: (occ) Mark occ_init_attribute() as __printf", " - ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF", " - gve: Correct ethtool rx_dropped calculation", " - spi: tegra210-quad: Return IRQ_HANDLED when timeout already processed", " transfer", " - spi: tegra210-quad: Move curr_xfer read inside spinlock", " - spi: tegra210-quad: Protect curr_xfer assignment in", " tegra_qspi_setup_transfer_one", " - spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer", " - spi: tegra210-quad: Protect curr_xfer clearing in", " tegra_qspi_non_combined_seq_xfer", " - spi: tegra114: Preserve SPI mode bits in def_command1_reg", " - ALSA: hda/realtek: Really fix headset mic for TongFang X6AR55xU.", " - PCI/ERR: Ensure error recoverability at all times", " - ALSA: hda/realtek: Add quirk for Acer Nitro AN517-55", " - PCI: qcom: Remove ASPM L0s support for MSM8996 SoC", " - HID: logitech: add HID++ support for Logitech MX Anywhere 3S", " - ALSA: hda/realtek: ALC269 fixup for Lenovo Yoga Book 9i 13IRU8 audio", " - net: phy: add phy_interface_weight()", " - net: phy: add phy_interface_copy()", " - net: sfp: pre-parse the module support", " - net: sfp: enhance quirk for Fibrestore 2.5G copper SFP module", " - net: sfp: convert sfp quirks to modify struct sfp_module_support", " - net: sfp: Fix quirk for Ubiquiti U-Fiber Instant SFP module", " - drm/amd/display: fix wrong color value mapping on MCM shaper LUT", " - drm/xe/query: Fix topology query pointer advance", " - ALSA: usb-audio: fix broken logic in snd_audigy2nx_led_update()", " - gpiolib-acpi: Update file references in the Documentation and", " MAINTAINERS", " - Upstream stable to v6.6.124, v6.12.70", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23214", " - btrfs: reject new transactions if the fs is fully read-only", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23213", " - drm/amd/pm: Disable MMIO access during SMU Mode 1 reset", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2025-71225", " - md: suspend array while updating raid_disks via sysfs", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2025-68823", " - ublk: fix deadlock when reading partition table", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23191", " - ALSA: aloop: Fix racy access at PCM trigger", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23215", " - x86/vmware: Fix hypercall clobbers", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23182", " - spi: tegra: Fix a memory leak in tegra_slink_probe()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23190", " - ASoC: amd: fix memory leak in acp3x pdm dma ops", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23254", " - net: gro: fix outer network offset", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23180", " - dpaa2-switch: add bounds check for if_id in IRQ handler", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23256", " - net: liquidio: Fix off-by-one error in VF setup_nic_devices() cleanup", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23257", " - net: liquidio: Fix off-by-one error in PF setup_nic_devices() cleanup", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23258", " - net: liquidio: Initialize netdev pointer before queue setup", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23206", " - dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zero", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23204", " - net/sched: cls_u32: use skb_header_pointer_careful()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23205", " - smb/client: fix memory leak in smb2_open_file()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23176", " - platform/x86: toshiba_haps: Fix memory leaks in add/remove routines", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23216", " - scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23193", " - scsi: target: iscsi: Fix use-after-free in", " iscsit_dec_session_usage_count()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23260", " - regmap: maple: free entry on mas_store_gfp() failure", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23179", " - nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23261", " - nvme-fc: release admin tagset if init fails", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23178", " - HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2025-71268", " - btrfs: fix reservation leak in some error paths when inserting inline", " extent", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2025-71270", " - LoongArch: Enable exception fixup for specific ADE subcode", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2025-71220", " - smb/server: call ksmbd_session_rpc_close() on error path in", " create_smb2_pipe()", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2025-71222", " - wifi: wlcore: ensure skb headroom before skb_push", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2025-71224", " - wifi: mac80211: ocb: skip rx_no_sta when interface is not joined", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23262", " - gve: Fix stats report corruption on queue count change", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2025-38201", " - netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23198", " - KVM: Don't clobber irqfd routing type when deassigning irqfd", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23264", " - Revert \"drm/amd: Check if ASPM is enabled from PCIe subsystem\"", "", " * Noble update: upstream stable patchset 2026-04-10 (LP: #2147841) //", " CVE-2026-23187", " - pmdomain: imx8m-blk-ctrl: fix out-of-range access of bc->domains", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543)", " - net/mlx5: Fix memory leak in esw_acl_ingress_lgcy_setup()", " - can: gs_usb: gs_usb_receive_bulk_callback(): fix error message", " - net: bcmasp: fix early exit leak with fixed phy", " - net: mvpp2: cls: Fix memory leak in mvpp2_ethtool_cls_rule_ins()", " - ipv6: use the right ifindex when replying to icmpv6 from localhost", " - ice: stop counting UDP csum mismatch as rx_errors", " - net/mlx5e: Report rx_discards_phy via rx_dropped", " - net/mlx5e: Account for netdev stats in ndo_get_stats64", " - net: bridge: fix static key check", " - net/mlx5e: Skip ESN replay window setup for IPsec crypto offload", " - scsi: firewire: sbp-target: Fix overflow in sbp_make_tpg()", " - ASoC: Intel: sof_es8336: fix headphone GPIO logic inversion", " - gpiolib: acpi: use BIT_ULL() for u64 mask in address space handler", " - dma/pool: distinguish between missing and exhausted atomic pools", " - pinctrl: meson: mark the GPIO controller as sleeping", " - riscv: compat: fix COMPAT_UTS_MACHINE definition", " - rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target", " - ASoC: fsl: imx-card: Do not force slot width to sample width", " - scsi: be2iscsi: Fix a memory leak in beiscsi_boot_get_sinfo()", " - ASoC: amd: yc: Add DMI quirk for Acer TravelMate P216-41-TCO", " - gpio: pca953x: mask interrupts in irq shutdown", " - scsi: qla2xxx: edif: Fix dma_free_coherent() size", " - mptcp: only reset subflow errors when propagated", " - selftests: mptcp: check no dup close events after error", " - selftests: mptcp: check subflow errors in close events", " - selftests: mptcp: join: fix local endp not being tracked", " - scripts: generate_rust_analyzer: Add compiler_builtins -> core dep", " - drm/amdgpu/soc21: fix xclk for APUs", " - drm/amdgpu/gfx10: fix wptr reset in KGQ init", " - drm/amdgpu/gfx11: fix wptr reset in KGQ init", " - mm/kfence: randomize the freelist on initialization", " - arm64/fpsimd: signal: Mandate SVE payload for streaming-mode state", " - arm64/fpsimd: signal: Consistently read FPSIMD context", " - btrfs: prevent use-after-free on page private data in", " btrfs_subpage_clear_uptodate()", " - net/sched: act_ife: convert comma to semicolon", " - pinctrl: lpass-lpi: implement .get_direction() for the GPIO driver", " - drm/msm/a6xx: fix bogus hwcg register updates", " - writeback: fix 100% CPU usage when dirtytime_expire_interval is 0", " - mptcp: avoid dup SUB_CLOSED events after disconnect", " - ksmbd: fix recursive locking in RPC handle list access", " - bpf/selftests: test_select_reuseport_kern: Remove unused header", " - can: at91_can: Fix memory leak in at91_can_probe()", " - net: phy: micrel: fix clk warning when removing the driver", " - net/mlx5: fs, Fix inverted cap check in tx flow table root disconnect", " - net/mlx5: Initialize events outside devlink lock", " - net/mlx5: Fix vhca_id access call trace use before alloc", " - bcache: fix improper use of bi_end_io", " - bcache: use bio cloning for detached device requests", " - bcache: fix I/O accounting leak in detached_dev_do_request", " - gpio: rockchip: Stop calling pinctrl for set_direction", " - mm/memory-failure: improve memory failure action_result messages", " - mm/memory-failure: fix redundant updates for already poisoned pages", " - mm/memory-failure: fix missing ->mf_stats count in hugetlb poison", " - mm/memory-failure: teach kill_accessing_process to accept hugetlb tail", " page pfn", " - gpiolib: acpi: Fix potential out-of-boundary left shift", " - rust: kbuild: support `-Cjump-tables=n` for Rust 1.93.0", " - pinctrl: qcom: sm8350-lpass-lpi: Merge with SC7280 to fix I2S2 and SWR", " TX pins", " - [Config] remove PINCTRL_SM8350_LPASS_LPI", " - Upstream stable to v6.6.123, v6.12.69", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23148", " - nvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23166", " - ice: Fix NULL pointer dereference in ice_vsi_set_napi_queues", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23151", " - Bluetooth: MGMT: Fix memory leak in set_ssp_complete", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23163", " - drm/amdgpu: fix NULL pointer dereference in", " amdgpu_gmc_filter_faults_remove", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23159", " - perf: sched: Fix perf crash with new is_user_task() helper", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2024-58096", " - wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2025-40039", " - ksmbd: Fix race condition in RPC handle list access", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23093", " - ksmbd: smbd: fix dma_unmap_sg() nents", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23102", " - arm64/fpsimd: signal: Fix restoration of SVE context", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23170", " - drm/imx/tve: fix probe device leak", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23168", " - flex_proportions: make fprop_new_period() hardirq safe", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23156", " - efivarfs: fix error propagation in efivar_entry_get()", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23167", " - nfc: nci: Fix race between rfkill and nci_unregister_device().", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23173", " - net/mlx5e: TC, delete flows only for existing peers", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23150", " - nfc: llcp: Fix memleak in nfc_llcp_send_ui_frame().", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23164", " - rocker: fix memory leak in rocker_world_port_post_fini()", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23172", " - net: wwan: t7xx: fix potential skb->frags overflow in RX path", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23212", " - bonding: annotate data-races around slave->last_rx", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23160", " - octeon_ep: Fix memory leak in octep_device_setup()", "", " * Noble update: upstream stable patchset 2026-04-08 (LP: #2147543) //", " CVE-2026-23146", " - Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work", "", " * CVE-2026-23394", " - af_unix: Give up GC if MSG_PEEK intervened.", "", " * [SRU] MIPI camera is not working after upgrading to 6.17-oem", " (LP: #2145171)", " - SAUCE: ACPI: respect items already in honor_dep before skipping", "", " * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless", " link power management is forced to max_performance (LP: #2144060)", " - ata: libata-core: disable LPM on ADATA SU680 SSD", "", " * intel_idle: add Clearwater Forest SoC support (LP: #2144006)", " - intel_idle: add Clearwater Forest SoC support", "", " * Noble kernel 6.8.0-108 does not compile when KASAN enabled (LP: #2144914)", " - mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN", "", " * Generic noble linux throws warning from file tegra-i2c.c (LP: #2143152)", " - i2c: tegra: Use internal reset when reset property is not available", "", " * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)", " - namespace: fix proc mount iteration", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465)", " - firmware: imx: scu-irq: Set mu_resource_id before get handle", " - efi/cper: Fix cper_bits_to_str buffer handling and return value", " - ASoC: codecs: wsa884x: fix codec initialisation", " - xfrm: Fix inner mode lookup in tunnel mode GSO segmentation", " - net: bridge: annotate data-races around fdb->{updated,used}", " - net: update netdev_lock_{type,name}", " - vsock/test: add a final full barrier after run all tests", " - net/mlx5e: Restore destroying state bit after profile cleanup", " - btrfs: store fs_info in space_info", " - btrfs: factor out init_space_info() from create_space_info()", " - btrfs: factor out check_removing_space_info() from", " btrfs_free_block_groups()", " - btrfs: introduce btrfs_space_info sub-group", " - btrfs: fix memory leaks in create_space_info() error paths", " - selftests: drv-net: fix RPS mask handling for high CPU numbers", " - ASoC: tlv320adcx140: fix word length", " - textsearch: describe @list member in ts_ops search", " - mm, kfence: describe @slab parameter in __kfence_obj_info()", " - dmaengine: xilinx_dma: Fix uninitialized addr_width when", " \"xlnx,addrwidth\" property is missing", " - phy: fsl-imx8mq-usb: Clear the PCS_TX_SWING_FULL field before using it", " - phy: phy-snps-eusb2: refactor constructs names", " - phy: drop probe registration printks", " - phy: broadcom: ns-usb3: Fix Wvoid-pointer-to-enum-cast warning (again)", " - i2c: qcom-geni: make sure I2C hub controllers can't use SE DMA", " - HID: usbhid: paper over wrong bNumDescriptor field", " - scsi: core: Fix error handler encryption support", " - ALSA: pcm: Improve the fix for race of buffer access at PCM OSS layer", " - can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.", " - x86/kaslr: Recognize all ZONE_DEVICE users as physaddr consumers", " - phy: rockchip: inno-usb2: fix communication disruption in gadget mode", " - phy: freescale: imx8m-pcie: assert phy reset during power on", " - phy: rockchip: inno-usb2: fix disconnection in gadget mode", " - phy: tegra: xusb: Explicitly configure HS_DISCON_LEVEL to 0x7", " - usb: dwc3: Check for USB4 IP_NAME", " - usb: core: add USB_QUIRK_NO_BOS for devices that hang on BOS descriptor", " - USB: OHCI/UHCI: Add soft dependencies on ehci_platform", " - USB: serial: option: add Telit LE910 MBIM composition", " - USB: serial: ftdi_sio: add support for PICAXE AXE027 cable", " - nvme-pci: disable secondary temp for Wodposit WPBSNM8", " - hrtimer: Fix softirq base check in update_needs_ipi()", " - EDAC/x38: Fix a resource leak in x38_probe1()", " - EDAC/i3200: Fix a resource leak in i3200_probe1()", " - tcpm: allow looking for role_sw device in the main node", " - x86/resctrl: Add missing resctrl initialization for Hygon", " - x86/resctrl: Fix memory bandwidth counter width for Hygon", " - mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free", " - LoongArch: Fix PMU counter allocation for mixed-type event groups", " - drm/amd/display: Bump the HDMI clock to 340MHz", " - drm/amd: Clean up kfd node on surprise disconnect", " - drm/amdkfd: fix a memory leak in device_queue_manager_init()", " - drm/nouveau/disp/nv50-: Set lock_core in curs507a_prepare", " - drm/vmwgfx: Fix an error return check in vmw_compat_shader_add()", " - dmaengine: apple-admac: Add \"apple,t8103-admac\" compatible", " - dmaengine: sh: rz-dmac: Fix rz_dmac_terminate_all()", " - dmaengine: ti: dma-crossbar: fix device leak on dra7x route allocation", " - dmaengine: ti: k3-udma: fix device leak on udma lookup", " - io_uring: move local task_work in exit cancel loop", " - posix-clock: Store file pointer in struct posix_clock_context", " - ptp: Add PHC file mode checks. Allow RO adjtime() without FMODE_WRITE.", " - selftest/ptp: update ptp selftest to exercise the gettimex options", " - testptp: Add option to open PHC in readonly mode", " - arm64: dts: qcom: sc8280xp: Add missing VDD_MXC links", " - hyperv-tlfs: Change prefix of generic HV_REGISTER_* MSRs to HV_MSR_*", " - Drivers: hv: Always do Hyper-V panic notification in hv_kmsg_dump()", " - btrfs: fix missing fields in superblock backup with BLOCK_GROUP_TREE", " - dt-bindings: power: qcom,rpmpd: document the SM8750 RPMh Power Domains", " - dt-bindings: power: qcom,rpmpd: add Turbo L5 corner", " - dt-bindings: power: qcom-rpmpd: split RPMh domains definitions", " - dt-bindings: power: qcom,rpmpd: Add SC8280XP_MXC_AO", " - pmdomain: qcom: rpmhpd: Add MXC to SC8280XP", " - ata: libata: Add cpr_log to ata_dev_print_features() early return", " - ata: libata-core: Introduce ata_dev_config_lpm()", " - ata: libata: Call ata_dev_config_lpm() for ATAPI devices", " - ata: libata: Print features also for ATAPI devices", " - ice: initialize ring_stats->syncp", " - ice: Avoid detrimental cleanup for bond during interface stop", " - igc: fix race condition in TX timestamp read for register 0", " - net: usb: dm9601: remove broken SR9700 support", " - selftests: net: fib-onlink-tests: Convert to use namespaces by default", " - can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on", " usb_submit_urb() error", " - amd-xgbe: avoid misleading per-packet error log", " - tools: ynl: Specify --no-line-number in ynl-regen.sh.", " - veth: fix data race in veth_get_ethtool_stats", " - octeontx2: cn10k: fix RX flowid TCAM mask handling", " - serial: 8250_pci: Fix broken RS485 for F81504/508/512", " - comedi: dmm32at: serialize use of paged registers", " - w1: fix redundant counter decrement in w1_attach_slave_device()", " - Revert \"nfc/nci: Add the inconsistency check between the input data", " length and count\"", " - Input: i8042 - add quirks for MECHREVO Wujie 15X Pro", " - Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA", " - scsi: storvsc: Process unsupported MODE_SENSE_10", " - arm64: dts: rockchip: remove dangerous max-link-speed from helios64", " - arm64: dts: rockchip: Fix voltage threshold for volume keys for", " Pinephone Pro", " - x86/kfence: avoid writing L1TF-vulnerable PTEs", " - comedi: Fix getting range information for subdevices 16 to 255", " - iio: adc: ad7280a: handle spi_setup() errors in probe()", " - kconfig: fix static linking of nconf", " - riscv: clocksource: Fix stimecmp update hazard on RV32", " - ALSA: usb: Increase volume range that triggers a warning", " - net: hns3: fix data race in hns3_fetch_stats", " - be2net: fix data race in be_get_new_eqd", " - net: hns3: fix wrong GENMASK() for HCLGE_FD_AD_COUNTER_NUM_M", " - net: hns3: fix the HCLGE_FD_AD_NXT_KEY error setting issue", " - usbnet: limit max_mtu based on device's hard_mtu", " - drm/amd/pm: Don't clear SI SMC table when setting power limit", " - drm/amd/pm: Workaround SI powertune issue on Radeon 430 (v2)", " - selftests: net: amt: wait longer for connection before sending packets", " - net: dsa: fix off-by-one in maximum bridge ID determination", " - octeontx2-af: Fix error handling", " - net: openvswitch: fix data race in ovs_vport_get_upcall_stats", " - vsock/test: fix seqpacket message bounds test", " - x86: make page fault handling disable interrupts properly", " - of: fix reference count leak in of_alias_scan()", " - of: platform: Use default match table for /firmware", " - iio: accel: iis328dq: fix gain values", " - iio: adc: ad9467: fix ad9434 vref mask", " - iio: chemical: scd4x: fix reported channel endianness", " - iio: dac: ad5686: add AD5695R to ad5686_chip_info_tbl", " - mmc: rtsx_pci_sdmmc: implement sdmmc_card_busy function", " - wifi: mwifiex: Fix a loop in mwifiex_update_ampdu_rxwinsize()", " - octeontx2: Fix otx2_dma_map_page() error return code", " - slimbus: core: fix runtime PM imbalance on report present", " - platform/x86: hp-bioscfg: Fix automatic module loading", " - perf/x86/intel: Do not enable BTS for guests", " - selftests/bpf: Check for timeout in perf_link test", " - mm/damon/sysfs-scheme: cleanup quotas subdirs on scheme dir setup", " failure", " - iio: core: add missing mutex_destroy in iio_dev_release()", " - iio: core: add separate lockdep class for info_exist_lock", " - mm/rmap: fix two comments related to huge_pmd_unshare()", " - arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s", " - iio: adc: exynos_adc: fix OF populate on driver rebind", " - dmaengine: stm32: dmamux: fix OF node leak on route allocation failure", " - mm: kmsan: fix poisoning of high-order non-compound pages", " - phy: phy-rockchip-inno-usb2: Use dev_err_probe() in the probe path", " - ASoC: codecs: wsa881x: Drop unused version readout", " - ASoC: codecs: wsa881x: fix unnecessary initialisation", " - ASoC: codecs: wsa883x: fix unnecessary initialisation", " - nvme-fc: rename free_ctrl callback to match name pattern", " - nvme-pci: do not directly handle subsys reset fallout", " - nvme: fix PCIe subsystem reset controller state transition", " - net: phy: fix phy_uses_state_machine()", " - pnfs/blocklayout: Fix memory leak in bl_parse_scsi()", " - drm/vmwgfx: Merge vmw_bo_release and vmw_bo_free functions", " - ALSA: hda/cirrus_scodec_test: Fix incorrect setup of gpiochip", " - ASoC: sdw_utils: cs42l43: Enable Headphone pin for LINEOUT jack type", " - selftests/landlock: Fix TCP bind(AF_UNSPEC) test case", " - xfs: Fix the return value of xfs_rtcopy_summary()", " - phy: ti: gmii-sel: fix regmap leak on probe failure", " - LoongArch: dts: loongson-2k0500: Add default interrupt controller", " address cells", " - LoongArch: dts: loongson-2k1000: Add default interrupt controller", " address cells", " - LoongArch: dts: loongson-2k1000: Fix i2c-gpio node names", " - LoongArch: dts: loongson-2k2000: Add default interrupt controller", " address cells", " - HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume", " blocking", " - HID: intel-ish-hid: Fix -Wcast-function-type-strict in", " devm_ishtp_alloc_workqueue()", " - xfs: set max_agbno to allow sparse alloc of last full inode chunk", " - selftests/bpf: Test invalid narrower ctx load", " - mm/page_alloc/vmstat: simplify refresh_cpu_vm_stats change detection", " - mm/page_alloc: batch page freeing in decay_pcp_high", " - ata: libata-sata: Improve link_power_management_supported sysfs", " attribute", " - igc: Restore default Qbv schedule when changing channels", " - vsock/virtio: Coalesce only linear skb", " - platform/x86/amd: Fix memory leak in wbrf_record()", " - drm/imagination: Wait for FW trace update command completion", " - ice: Fix persistent failure in ice_get_rxfh", " - sched/fair: Fix pelt clock sync when entering idle", " - drm/nouveau: add missing DCB connector types", " - drm/nouveau: implement missing DCB connector types; gracefully handle", " unknown connectors", " - dpll: Prevent duplicate registrations", " - mei: trace: treat reg parameter as string", " - s390/ap: Fix wrong APQN fill calculation", " - net: sfp: add potron quirk to the H-COM SPP425H-GAB4 SFP+ Stick", " - gpio: cdev: Correct return code on memory allocation failure", " - dmaengine: ti: k3-udma: Enable second resource range for BCDMA and", " PKTDMA", " - exfat: fix refcount leak in exfat_find", " - accel/ivpu: Fix race condition when unbinding BOs", " - btrfs: fix racy bitfield write in btrfs_clear_space_info_full()", " - vsock/virtio: Move length check to callers of virtio_vsock_skb_rx_put()", " - vsock/virtio: Rename virtio_vsock_alloc_skb()", " - vsock/virtio: Move SKB allocation lower-bound check to callers", " - vsock/virtio: Rename virtio_vsock_skb_rx_put()", " - vhost/vsock: Allocate nonlinear SKBs for handling large receive buffers", " - vsock/virtio: Allocate nonlinear SKBs for handling large transmit", " buffers", " - net: Introduce skb_copy_datagram_from_iter_full()", " - vsock/virtio: Fix message iterator handling on transmit path", " - Upstream stable to v6.6.122, v6.12.67, v6.12.68", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-38591", " - bpf: Reject narrower access to pointer ctx fields", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23035", " - net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-22996", " - net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23000", " - net/mlx5e: Fix crash on profile change rollback failure", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23053", " - NFS: Fix a deadlock involving nfs_release_folio()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23050", " - pNFS: Fix a deadlock when returning a delegation during open()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23005", " - x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2024-58097", " - wifi: ath11k: fix RCU stall while reaping monitor destination ring", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-68365", " - fs/ntfs3: Initialize allocated memory before use", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-37926", " - ksmbd: fix use-after-free in ksmbd_session_rpc_open", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23030", " - phy: rockchip: inno-usb2: Fix a double free bug in", " rockchip_usb2phy_probe()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23025", " - mm/page_alloc: prevent pcp corruption with SMP=n", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71186", " - dmaengine: stm32: dmamux: fix device leak on route allocation", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23078", " - ALSA: scarlett2: Fix buffer overflow in config retrieval", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23142", " - mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir", " setup failure", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23075", " - can: esd_usb: esd_usb_read_bulk_callback(): fix URB memory leak", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-68725", " - bpf: Do not let BPF test infra emit invalid GSO types to stack", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23097", " - migrate: correct lock ordering for hugetlb file folios", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23108", " - can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23080", " - can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23061", " - can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23058", " - can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23085", " - irqchip/gic-v3-its: Avoid truncating memory addresses", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23116", " - pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23098", " - netrom: fix double-free in nr_route_frame()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23063", " - uacce: ensure safe queue release with state management", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23056", " - uacce: implement mremap in uacce_vm_ops to return -EPERM", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23094", " - uacce: fix isolate sysfs check condition", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23096", " - uacce: fix cdev handling in the cleanup path", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23091", " - intel_th: fix device leak on output open()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23088", " - tracing: Fix crash on synthetic stacktrace field usage", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23090", " - slimbus: core: fix device reference leak on report present", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23128", " - arm64: Set __nocfi on swsusp_arch_resume()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23107", " - arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23073", " - wifi: rsi: Fix memory corruption due to not set vif driver data size", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23135", " - wifi: ath12k: fix dma_free_coherent() pointer", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23133", " - wifi: ath10k: fix dma_free_coherent() pointer", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71200", " - mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400", " mode", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23089", " - ALSA: usb-audio: Fix use-after-free in snd_usb_mixer_free()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23076", " - ALSA: ctxfi: Fix potential OOB access in audio mixer handling", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71199", " - iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc", " driver", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23101", " - leds: led-class: Only Add LED to leds_list when it is fully ready", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23064", " - net/sched: act_ife: avoid possible NULL deref", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23086", " - vsock/virtio: cap TX credit to local buffer size", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23069", " - vsock/virtio: fix potential underflow in virtio_transport_get_credit()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23119", " - bonding: provide a net pointer to __skb_flow_dissect()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23084", " - be2net: Fix NULL pointer dereference in be_cmd_get_mac_from_list", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23124", " - ipv6: annotate data-race in ndisc_router_discovery()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23121", " - mISDN: annotate data-race around dev->work", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23126", " - netdevsim: fix a race issue related to the operation on bpf_bound_progs", " list", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23059", " - scsi: qla2xxx: Sanitize payload size to prevent member overflow", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23110", " - scsi: core: Wake up the error handler when final completions race", " against each other", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23071", " - regmap: Fix race condition in hwspinlock irqsave routine", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23068", " - spi: spi-sprd-adi: Fix double free in probe error path", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23123", " - interconnect: debugfs: initialize src_node and dst_node to empty strings", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71198", " - iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event", " detection", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23113", " - io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23062", " - platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23131", " - platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23087", " - scsi: xen: scsiback: Fix potential memory leak in scsiback_remove()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71197", " - w1: therm: Fix off-by-one buffer overflow in alarms_store", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23105", " - net/sched: qfq: Use cl_is_active to determine whether class is active in", " qfq_rm_from_ag", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23103", " - ipvlan: Make the addrs_lock be per port", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23120", " - l2tp: avoid one data-race in l2tp_tunnel_del_work()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23083", " - fou: Don't allow 0 for FOU_ATTR_IPPROTO.", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23095", " - gue: Fix skb memleak with inner IP protocol 0.", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23125", " - sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23099", " - bonding: limit BOND_MODE_8023AD to Ethernet devices", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71194", " - btrfs: fix deadlock in wait_current_trans() due to ignored transaction", " type", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71185", " - dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23026", " - dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71188", " - dmaengine: lpc18xx-dmamux: fix device leak on route allocation", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71163", " - dmaengine: idxd: fix device leaks on compat bind and unbind", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71189", " - dmaengine: dw: dmamux: fix OF node leak on route allocation failure", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71190", " - dmaengine: bcm-sba-raid: fix device leak on probe", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71191", " - dmaengine: at_hdmac: fix device leak on of_dma_xlate()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23049", " - drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23144", " - mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23145", " - ext4: fix iloc.bh leak in ext4_xattr_inode_update_ref", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-22997", " - net: can: j1939: j1939_xtp_rx_rts_session_active(): deactivate session", " upon receiving the second rts", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23031", " - can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23032", " - null_blk: fix kmemleak by releasing references to fault configfs items", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23033", " - dmaengine: omap-dma: fix dma_pool resource leak in error paths", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71196", " - phy: stm32-usphyc: Fix off by one in probe()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71193", " - phy: qcom-qusb2: Fix NULL pointer dereference on early suspend", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71162", " - dmaengine: tegra-adma: Fix use-after-free", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2025-71195", " - dmaengine: xilinx: xdma: Fix regmap max_register", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23006", " - ASoC: tlv320adcx140: fix null pointer", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-22999", " - net/sched: sch_qfq: do not free existing class in qfq_change_class()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23010", " - ipv6: Fix use-after-free in inet6_addr_del().", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23054", " - net: hv_netvsc: reject RSS hash key programming without RX indirection", " table", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23011", " - ipv4: ip_gre: make ipgre_header() robust", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23001", " - macvlan: fix possible UAF in macvlan_forward_source()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23003", " - ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23141", " - btrfs: send: check for inline extents in range_is_hole_in_parent()", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-22998", " - nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23037", " - can: etas_es58x: allow partial RX URB allocation to succeed", "", " * Noble update: upstream stable patchset 2026-03-26 (LP: #2146465) //", " CVE-2026-23038", " - pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058)", " - NFSD: Fix permission check for read access to executable-only files", " - atm: Fix dma_free_coherent() size", " - mei: me: add nova lake point S DID", " - lib/crypto: aes: Fix missing MMU protection for AES S-box", " - counter: 104-quad-8: Fix incorrect return value in IRQ handler", " - drm/pl111: Fix error handling in pl111_amba_probe", " - drm/radeon: Remove __counted_by from ClockInfoArray.clockInfo[]", " - gpio: rockchip: mark the GPIO controller as sleeping", " - pinctrl: qcom: lpass-lpi: mark the GPIO controller as sleeping", " - net: Add locking to protect skb->dev access in ip_output", " - nfsd: Fix a regression in nfsd_setattr()", " - nfsd: Fix NFSv3 atomicity bugs in nfsd_setattr()", " - nfsd: set security label during create operations", " - csky: fix csky_cmpxchg_fixup not working", " - ARM: 9461/1: Disable HIGHPTE on PREEMPT_RT kernels", " - alpha: don't reference obsolete termio struct for TC* constants", " - dm-snapshot: fix 'scheduling while atomic' on real-time kernels", " - NFSv4: ensure the open stateid seqid doesn't go backwards", " - NFS: Fix up the automount fs_context to use the correct cred", " - smb/client: fix NT_STATUS_UNABLE_TO_FREE_VM value", " - smb/client: fix NT_STATUS_DEVICE_DOOR_OPEN value", " - smb/client: fix NT_STATUS_NO_DATA_DETECTED value", " - scsi: ipr: Enable/disable IRQD_NO_BALANCING during reset", " - scsi: ufs: core: Fix EH failure after W-LUN resume error", " - scsi: Revert \"scsi: libsas: Fix exp-attached device scan after probe", " failure scanned in again after probe failed\"", " - arm64: dts: add off-on-delay-us for usdhc2 regulator", " - ARM: dts: imx6q-ba16: fix RTC interrupt level", " - arm64: dts: imx8mp: Fix LAN8740Ai PHY reference clock on DH electronics", " i.MX8M Plus DHCOM", " - netfilter: nft_synproxy: avoid possible data-race on update operation", " - gpio: pca953x: Add support for level-triggered interrupts", " - gpio: pca953x: handle short interrupt pulses on PCAL devices", " - netfilter: nf_tables: fix memory leak in nf_tables_newrule()", " - bridge: fix C-VLAN preservation in 802.1ad vlan_tunnel egress", " - inet: ping: Fix icmp out counting", " - netdev: preserve NETIF_F_ALL_FOR_ALL across TSO updates", " - net/mlx5e: Don't print error message due to invalid module", " - net: wwan: iosm: Fix memory leak in ipc_mux_deinit()", " - bnxt_en: Fix potential data corruption with HW GRO/LRO", " - net: enetc: fix build warning when PAGE_SIZE is greater than 128K", " - arp: do not assume dev_hard_header() does not change skb->head", " - ALSA: ac97bus: Use guard() for mutex locks", " - NFS: trace: show TIMEDOUT instead of 0x6e", " - nfs_common: factor out nfs_errtbl and nfs_stat_to_errno", " - NFSD: Remove NFSERR_EAGAIN", " - bpf: Fix an issue in bpf_prog_test_run_xdp when page size greater than", " 4K", " - bpf: Make variables in bpf_prog_test_run_xdp less confusing", " - bpf: Support specifying linear xdp packet data size for", " BPF_PROG_TEST_RUN", " - powercap: fix race condition in register_control_type()", " - powercap: fix sscanf() error return value handling", " - ALSA: usb-audio: Update for native DSD support quirks", " - ASoC: amd: yc: Add quirk for Honor MagicBook X16 2025", " - ASoC: fsl_sai: Add missing registers to cache default", " - scsi: sg: Fix occasional bogus elapsed time that exceeds timeout", " - bpf: test_run: Fix ctx leak in bpf_prog_test_run_xdp error path", " - ASoC: rockchip: Fix Wvoid-pointer-to-enum-cast warning (again)", " - btrfs: tracepoints: use btrfs_root_id() to get the id of a root", " - crypto: qat - fix duplicate restarting msg during AER error", " - netfilter: nft_set_pipapo: fix range overlap detection", " - vsock: Make accept()ed sockets use custom setsockopt()", " - btrfs: only enforce free space tree if v1 cache is required for bs < ps", " cases", " - riscv: pgtable: Cleanup useless VA_USER_XXX definitions", " - idpf: keep the netdev when a reset fails", " - net: sfp: extend Potron XGSPON quirk to cover additional EEPROM variant", " - ata: libata-core: Disable LPM on ST2000DM008-2FR102", " - drm/amd/display: Fix DP no audio issue", " - ALSA: hda/realtek: enable woofer speakers on Medion NM14LNL", " - spi: cadence-quadspi: Prevent lost complete() call during indirect read", " - ALSA: hda: intel-dsp-config: Prefer legacy driver as fallback", " - Upstream stable to v6.6.121, v6.12.66", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2025-71184", " - btrfs: fix NULL dereference on root when tracing inode eviction", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2025-71182", " - can: j1939: make j1939_session_activate() fail if device is no longer", " registered", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2025-71160", " - netfilter: nf_tables: avoid chain re-validation if possible", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22994", " - bpf: Fix reference count leak in bpf_prog_test_run_xdp()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-23140", " - bpf, test_run: Subtract size of xdp_frame from allowed metadata size", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2025-71192", " - ALSA: ac97: fix a double free in snd_ac97_controller_register()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-23021", " - net: usb: pegasus: fix memory leak in update_eth_regs_async()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22976", " - net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate", " in qfq_reset", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22979", " - net: fix memory leak in skb_segment_list for GRO packets", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22977", " - net: sock: fix hardened usercopy panic in sock_recv_errqueue", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22982", " - net: mscc: ocelot: Fix crash when adding interface under a lag", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-23019", " - net: marvell: prestera: fix NULL dereference on devlink_alloc() failure", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-23139", " - netfilter: nf_conncount: update last_gc only when GC has been performed", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2025-40149", " - tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2025-68803", " - NFSD: NFSv4 file creation neglects setting ACL", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-23047", " - libceph: make calc_target() set t->paused, not just clear it", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-23136", " - libceph: reset sparse-read state in osd_fault()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22992", " - libceph: return the handler error from mon_handle_auth_done()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22991", " - libceph: make free_choose_arg_map() resilient to partial allocation", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22990", " - libceph: replace overzealous BUG_ON in osdmap_apply_incremental()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22984", " - libceph: prevent potential out-of-bounds reads in handle_auth_done()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22978", " - wifi: avoid kernel-infoleak from struct iw_point", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2025-71180", " - counter: interrupt-cnt: Drop IRQF_NO_THREAD flag", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2025-71183", " - btrfs: always detect conflicting inodes when logging inode refs", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-23020", " - net: 3com: 3c59x: fix possible null dereference in vortex_probe1()", "", " * Noble update: upstream stable patchset 2026-03-12 (LP: #2144058) //", " CVE-2026-22980", " - nfsd: provide locking for v4_end_grace", "", " * CVE-2024-50004", " - drm/amd/display: update DML2 policy", " EnhancedPrefetchScheduleAccelerationFinal DCN35", "", " * CVE-2026-23274", " - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels", "", " * CVE-2026-23351", " - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase", "", " * CVE-2026-23231", " - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()", "", " * macvlan: observe an RCU grace period in macvlan_common_newlink() error", " path (LP: #2144380) // CVE-2026-23209", " - macvlan: observe an RCU grace period in macvlan_common_newlink() error", " path", "", " * CVE-2026-23112", " - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec", "" ], "package": "linux", "version": "6.8.0-112.112", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2147982, 2147447, 2147400, 2147065, 2144577, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147841, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2147543, 2145171, 2144060, 2144006, 2144914, 2143152, 2143083, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2146465, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144058, 2144380 ], "author": "Mehmet Basaran ", "date": "Sun, 12 Apr 2026 06:19:35 +0300" } ], "notes": "linux-modules-6.8.0-117-generic version '6.8.0-117.117' (source package linux version '6.8.0-117.117') was added. linux-modules-6.8.0-117-generic version '6.8.0-117.117' has the same source package name, linux, as removed package linux-modules-6.8.0-110-generic. As such we can use the source package version of the removed package, '6.8.0-110.110', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-image-6.8.0-110-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-110.110", "version": "6.8.0-110.110" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-6.8.0-110-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-110.110", "version": "6.8.0-110.110" }, "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 daily image serial 20260429 to 20260521", "from_series": "noble", "to_series": "noble", "from_serial": "20260429", "to_serial": "20260521", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }